https://revspace.nl/api.php?action=feedcontributions&user=Bertrik+Sikken&feedformat=atomRevSpace - User contributions [en-gb]2024-03-19T08:02:28ZUser contributionsMediaWiki 1.32.1https://revspace.nl/index.php?title=FMCWRadar&diff=32175FMCWRadar2024-03-15T15:09:47Z<p>Bertrik Sikken: /* RD-03E */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:aithinker-rd03-1.png|thumb|right|aithinker rd-03]]<br />
[[File:aithinker-rd03-2.png|thumb|right|aithinker rd-03]]<br />
<br />
Parts:<br />
* radar chip: S3KM1110<br />
* controller chip: F003F17 / 2L6T13B, PY32F003F17U<br />
<br />
This thing outputs ASCII strings over a serial port at 115200, for example:<br />
<pre><br />
ON<br />
Range 46<br />
</pre><br />
<br />
That appears to be all.<br />
<br />
=== RD-03E ===<br />
Product page: http://www.ai-thinker.com/pro_view-141.html<br />
<br />
* E230K8 / BSK4KM / JJ 2331 / GD ARM<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=32174FMCWRadar2024-03-15T14:34:49Z<p>Bertrik Sikken: /* Ai Thinker */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:aithinker-rd03-1.png|thumb|right|aithinker rd-03]]<br />
[[File:aithinker-rd03-2.png|thumb|right|aithinker rd-03]]<br />
<br />
Parts:<br />
* radar chip: S3KM1110<br />
* controller chip: F003F17 / 2L6T13B, PY32F003F17U<br />
<br />
This thing outputs ASCII strings over a serial port at 115200, for example:<br />
<pre><br />
ON<br />
Range 46<br />
</pre><br />
<br />
That appears to be all.<br />
<br />
=== RD-03E ===<br />
* E230K8 / BSK4KM / JJ 2331 / GD ARM<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Sensor-data-bridge&diff=32154Sensor-data-bridge2024-03-10T22:17:25Z<p>Bertrik Sikken: </p>
<hr />
<div>{{Project<br />
|Name=sensor-data-bridge<br />
|Picture=loraluftdatenforwarder.png<br />
|Omschrijving=Collects sensor data, forwards it to sensor.community/opensense/etc<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== What is this ==<br />
This is a companion project of [[LoraWanDustSensor]].<br />
<br />
It takes airborne particulate matter measurement data transferred through TheThingsNetwork and forwards it to online databases:<br />
* http://sensor.community (formerly Luftdaten), <br />
* http://opensensemap.org and <br />
* <s>https://cayenne.mydevices.com</s><br />
<br />
Project on Github: https://github.com/bertrik/sensor-data-bridge<br />
<br />
Unofficial sensor.community API documentation: https://api-sensor-community.bessarabov.com/<br />
<br />
=== Features ===<br />
* Picks up particulate matter measurement data received through TheThingsNetwork, using their "v3" infrastructure<br />
* Forwards measurement data to https://sensor.community<br />
* Forwards measurement data to https://opensensemap.org, you can configure the opensense-id by adding a device attribute in TheThingsNetwork console<br />
* -Forwards measurement data to https://cayenne.mydevices.com, you configure the username/password/clientid by adding a device attribute in TheThingsNetwork console-<br />
* Supports Cayenne payload format for the data encoding, a custom payload format for SPS30 data (includes particle counts)<br />
* Supports JSON payload format for the data encoding, you can specify in the config file which JSON fields are used<br />
* Handles particulate matter data (PM10, PM4.0, PM2.5, PM1.0), temperature, humidity, barometric pressure<br />
* Handles sound/noise data (LA EQ, and min/max value)<br />
* Can be run as a systemd service, so it automatically restarts in case the software would crash, server is restarted, etc<br />
<br />
=== Next steps ===<br />
* add support for geolocation through a scan of surrounding WiFi access-points and a geolocation service (google, mozilla)<br />
* add support for NB-IOT modem with t-mobile backend, see my [[Sim7020]] project<br />
* add support for other backends, e.g. feinstaub-app?<br />
<br />
== Requirements ==<br />
You need the following:<br />
* a server that is always on and connected to the internet, can be Linux or Windows<br />
* a Java installation (<b>JDK</b> to compile), at least version 17<br />
* some configuration on TheThingsNetwork side<br />
* some configuration of my application (YAML file)<br />
<br />
== Compilation ==<br />
(not needed if you use the docker image)<br />
To compile the software:<br />
* clone the software from my github archive<br />
git clone https://github.com/bertrik/sensor-data-bridge.git<br />
* enter the application directory<br />
cd sensor-data-bridge<br />
* run the gradle script to build the software (Linux):<br />
./gradlew assemble<br />
or (Windows):<br />
gradlew assemble<br />
* the application zip & tar is now available in sensor-data-bridge/sensor-data-bridge/build/distributions<br />
<br />
To update to the latest version:<br />
* Update software from github archive:<br />
git pull<br />
* perform the last two steps above again<br />
<br />
== Installation ==<br />
=== run as docker/podman container ===<br />
How to run in docker/podman:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
(or use nano, gedit, whatever)<br />
* Start the container:<br />
docker-compose up<br />
<br />
=== installation from raw tar ===<br />
Unzip the distribution file somewhere on your system.<br />
I put it in my home directory, for example<br />
cd<br />
tar xvf code/sensor-data-bridge/sensor-data-bridge/build/distributions/sensor-data-bridge.tar<br />
<br />
== Configuration ==<br />
<br />
=== Node configuration ===<br />
The particulate matter measurement device needs to send data in the Cayenne format.<br />
I used the following conventions:<br />
* PM10 is encoded as analog value on channel 1<br />
* PM2.5 is encoded as analog value on channel 2<br />
* PM1.0 is encoded as analog value on channel 0 (optional)<br />
* PM4.0 is encoded as analog value on channel 4 (optional)<br />
* Temperature is encoded using standard Cayenne encoding (optional)<br />
* Humidity is encoded using standard Cayenne encoding (optional)<br />
* Barometric pressure is encoded using standard Cayenne encoding (optional)<br />
<br />
The SPS30 produces mass concentration data in 4 categories, particle count in 5 categories, plus particle size.<br />
Format:<br />
* 16-bit (big endian) PM1.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM2.5 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM4.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM10 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM0.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM1.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM2.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM4.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM10 number concentration (unit 1)<br />
* 16-bit (big endian) typical particle size (unit nm)<br />
<br />
A total of 20 bytes. This is sent on LoRaWAN port 30.<br />
Temperature and humidity is not encoded.<br />
<br />
In case your node uses a payload decoder in the TTN console, you can configure the sensor-data-bridge with the name of the JSON property:<br />
* 'path' is a pointer inside the decoded JSON payload that contains the value, e.g. "lc/avg"<br />
* 'item' is an internal id in the sensor-data-bridge, e.g. "PM10", see https://github.com/bertrik/sensor-data-bridge/blob/master/sensor-data-bridge/src/main/java/nl/bertriksikken/pm/ESensorItem.java<br />
<br />
=== TheThingsNetwork application/device configuration ===<br />
[[File:TtnEditApiKey.png|thumb|right|TTN API key rights]]<br />
<br />
You need to define an 'application' on TheTheThingsNetwork.<br />
<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
* You need an 'application', create a new one, or use an existing one<br />
* Within the application you need a 'device', so create a new one, or use an existing one:<br />
** Use OTAA, LoRaMac version 1.0.3<br />
** Enter the device EUI as displayed on the display<br />
** Use the application keys as specified in my [[LoraWanDustSensor]] page<br />
* You need an API key<br />
** Create this on the TTN console, grant individual rights as shown in the screenshot<br />
** NOTE: you have only one chance to copy this key somewhere, so copy/paste it locally to a text file or something<br />
<br />
=== Configuration ===<br />
To configure the application:<br />
* Start the application without a configuration file, this will create a default template, stop the application again<br />
cd sensor-data-bridge<br />
bin/sensor-data-bridge<br />
(ctrl-C)<br />
* Edit the configuration YAML file, example:<br />
<br />
<pre><br />
---<br />
ttn:<br />
mqtt_url: "tcp://eu1.cloud.thethings.network"<br />
identity_server_url: "https://eu1.cloud.thethings.network"<br />
identity_server_timeout: 20<br />
apps:<br />
- name: "particulatematter"<br />
key: "NNSXS......."<br />
encoding: "CAYENNE"<br />
senscom:<br />
url: "https://api.sensor.community"<br />
timeout: 20<br />
opensense:<br />
url: "https://api.opensensemap.org"<br />
timeout: 20<br />
</pre><br />
<br />
So:<br />
* enter the name of your application<br />
* enter the TTN API key you saved earlier<br />
* other defaults are probably OK<br />
<br />
=== Sensor.community ===<br />
TODO<br />
* Go to https://devices.sensor.community/ and log in<br />
* Register a node with id 'TTN-<device-EUI-as-shown-on-display>' (without the spaces or hyphens, e.g. 'TTN-0000547AF1BF713C')<br />
* Register it with the proper configuration, e.g. SDS011 with BME280<br />
* In the TTN console, add a device attribute with name 'senscom-id' and value 'TTN-<device-EUI-as-shown-on-display>'<br />
<br />
=== Opensensemap ===<br />
* Go to opensensemap.org and log in<br />
** Create an opensense node with the proper configuration<br />
** Copy the opensensenmap 'box id', a long hexadecimal string<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
** Add an attribute for the device, under 'General settings', name = 'opensense-id', value = boxid that you copied from opensensemap.org<br />
* The mapping from TTN-id to boxid is refreshed by the forwarder once an hour, so within an hour the forwarding to opensensemap.org starts<br />
<br />
== Development ==<br />
<br />
== Forwarding noise data ==<br />
How it is encoded in the sensor.community firmware:<br />
* Three values are sent in the JSON to sensor.community:<br />
** "noise_LAeq", value in dB(A)<br />
** "noise_LA_min", value in dB(A)<br />
** "noise_LA_max", value in dB(A)<br />
<br />
Values are read from the noise sensor as follows:<br />
* call to dnms_calculate_leq()<br />
* call to dnms_read_data_ready(&data_ready) returns 0 if OK and (data_ready != 0)<br />
* call to dnms_read_leq(&dnms_values) returns 0 if OK<br />
* firmware applies a "correction" by adding a fixed offset<br />
<br />
Measurement values are encoded as 32-bit units, interpreted as 32-bit floats.<br />
<br />
References:<br />
* DNMS is read at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3392<br />
* DNMS is formatted in the JSON at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3405<br />
* DNMS I2C code is at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/dnms_i2c.cpp</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Sensor-data-bridge&diff=32153Sensor-data-bridge2024-03-10T22:14:34Z<p>Bertrik Sikken: /* run as docker container */</p>
<hr />
<div>{{Project<br />
|Name=sensor-data-bridge<br />
|Picture=loraluftdatenforwarder.png<br />
|Omschrijving=Collects sensor data, forwards it to sensor.community/opensense/etc<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== What is this ==<br />
This is a companion project of [[LoraWanDustSensor]].<br />
<br />
It takes airborne particulate matter measurement data transferred through TheThingsNetwork and forwards it to online databases:<br />
* http://sensor.community (formerly Luftdaten), <br />
* http://opensensemap.org and <br />
* <s>https://cayenne.mydevices.com</s><br />
<br />
Project on Github: https://github.com/bertrik/sensor-data-bridge<br />
<br />
Unofficial sensor.community API documentation: https://api-sensor-community.bessarabov.com/<br />
<br />
=== Features ===<br />
* Picks up particulate matter measurement data received through TheThingsNetwork, using their "v3" infrastructure<br />
* Forwards measurement data to https://sensor.community<br />
* Forwards measurement data to https://opensensemap.org, you can configure the opensense-id by adding a device attribute in TheThingsNetwork console<br />
* Forwards measurement data to https://cayenne.mydevices.com, you configure the username/password/clientid by adding a device attribute in TheThingsNetwork console <br />
* Supports Cayenne payload format for the data encoding, a custom payload format for SPS30 data (includes particle counts)<br />
* Supports JSON payload format for the data encoding, you can specify in the config file which JSON fields are used<br />
* Handles particulate matter data (PM10, PM4.0, PM2.5, PM1.0), temperature, humidity, barometric pressure<br />
* Handles sound/noise data (LA EQ, and min/max value)<br />
* Can be run as a systemd service, so it automatically restarts in case the software would crash<br />
<br />
=== Next steps ===<br />
* add support for geolocation through a scan of surrounding WiFi access-points and a geolocation service (google, mozilla), see h<br />
* add support for NB-IOT modem with t-mobile backend, see my [[Sim7020]] project<br />
* add support for other backends, e.g. feinstaub-app?<br />
<br />
== Requirements ==<br />
You need the following:<br />
* a server that is always on and connected to the internet, can be Linux or Windows<br />
* a Java installation (<b>JDK</b> to compile), at least version 8<br />
* some configuration on TheThingsNetwork side<br />
* some configuration of my application (YAML file)<br />
<br />
== Compilation ==<br />
To compile the software:<br />
* clone the software from my github archive<br />
git clone https://github.com/bertrik/sensor-data-bridge.git<br />
* enter the application directory<br />
cd sensor-data-bridge<br />
* run the gradle script to build the software (Linux):<br />
./gradlew assemble<br />
or (Windows):<br />
gradlew assemble<br />
* the application zip & tar is now available in sensor-data-bridge/sensor-data-bridge/build/distributions<br />
<br />
To update to the latest version:<br />
* Update software from github archive:<br />
git pull<br />
* perform the last two steps above again<br />
<br />
== Installation ==<br />
<br />
<br />
=== run as docker/podman container ===<br />
How to run in docker/podman:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
(or use nano, gedit, whatever)<br />
* Start the container:<br />
docker-compose up<br />
<br />
=== installation from raw tar ===<br />
Unzip the distribution file somewhere on your system.<br />
I put it in my home directory, for example<br />
cd<br />
tar xvf code/sensor-data-bridge/sensor-data-bridge/build/distributions/sensor-data-bridge.tar<br />
<br />
== Configuration ==<br />
<br />
=== Node configuration ===<br />
The particulate matter measurement device needs to send data in the Cayenne format.<br />
I used the following conventions:<br />
* PM10 is encoded as analog value on channel 1<br />
* PM2.5 is encoded as analog value on channel 2<br />
* PM1.0 is encoded as analog value on channel 0 (optional)<br />
* PM4.0 is encoded as analog value on channel 4 (optional)<br />
* Temperature is encoded using standard Cayenne encoding (optional)<br />
* Humidity is encoded using standard Cayenne encoding (optional)<br />
* Barometric pressure is encoded using standard Cayenne encoding (optional)<br />
<br />
The SPS30 produces mass concentration data in 4 categories, particle count in 5 categories, plus particle size.<br />
Format:<br />
* 16-bit (big endian) PM1.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM2.5 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM4.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM10 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM0.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM1.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM2.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM4.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM10 number concentration (unit 1)<br />
* 16-bit (big endian) typical particle size (unit nm)<br />
<br />
A total of 20 bytes. This is sent on LoRaWAN port 30.<br />
Temperature and humidity is not encoded.<br />
<br />
In case your node uses a payload decoder in the TTN console, you can configure the sensor-data-bridge with the name of the JSON property:<br />
* 'path' is a pointer inside the decoded JSON payload that contains the value, e.g. "lc/avg"<br />
* 'item' is an internal id in the sensor-data-bridge, e.g. "PM10", see https://github.com/bertrik/sensor-data-bridge/blob/master/sensor-data-bridge/src/main/java/nl/bertriksikken/pm/ESensorItem.java<br />
<br />
=== TheThingsNetwork application/device configuration ===<br />
[[File:TtnEditApiKey.png|thumb|right|TTN API key rights]]<br />
<br />
You need to define an 'application' on TheTheThingsNetwork.<br />
<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
* You need an 'application', create a new one, or use an existing one<br />
* Within the application you need a 'device', so create a new one, or use an existing one:<br />
** Use OTAA, LoRaMac version 1.0.3<br />
** Enter the device EUI as displayed on the display<br />
** Use the application keys as specified in my [[LoraWanDustSensor]] page<br />
* You need an API key<br />
** Create this on the TTN console, grant individual rights as shown in the screenshot<br />
** NOTE: you have only one chance to copy this key somewhere, so copy/paste it locally to a text file or something<br />
<br />
=== Configuration ===<br />
To configure the application:<br />
* Start the application without a configuration file, this will create a default template, stop the application again<br />
cd sensor-data-bridge<br />
bin/sensor-data-bridge<br />
(ctrl-C)<br />
* Edit the configuration YAML file, example:<br />
<br />
<pre><br />
---<br />
ttn:<br />
mqtt_url: "tcp://eu1.cloud.thethings.network"<br />
identity_server_url: "https://eu1.cloud.thethings.network"<br />
identity_server_timeout: 20<br />
apps:<br />
- name: "particulatematter"<br />
key: "NNSXS......."<br />
encoding: "CAYENNE"<br />
senscom:<br />
url: "https://api.sensor.community"<br />
timeout: 20<br />
opensense:<br />
url: "https://api.opensensemap.org"<br />
timeout: 20<br />
</pre><br />
<br />
So:<br />
* enter the name of your application<br />
* enter the TTN API key you saved earlier<br />
* other defaults are probably OK<br />
<br />
=== Sensor.community ===<br />
TODO<br />
* Go to https://devices.sensor.community/ and log in<br />
* Register a node with id 'TTN-<device-EUI-as-shown-on-display>' (without the spaces or hyphens, e.g. 'TTN-0000547AF1BF713C')<br />
* Register it with the proper configuration, e.g. SDS011 with BME280<br />
* In the TTN console, add a device attribute with name 'senscom-id' and value 'TTN-<device-EUI-as-shown-on-display>'<br />
<br />
=== Opensensemap ===<br />
* Go to opensensemap.org and log in<br />
** Create an opensense node with the proper configuration<br />
** Copy the opensensenmap 'box id', a long hexadecimal string<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
** Add an attribute for the device, under 'General settings', name = 'opensense-id', value = boxid that you copied from opensensemap.org<br />
* The mapping from TTN-id to boxid is refreshed by the forwarder once an hour, so within an hour the forwarding to opensensemap.org starts<br />
<br />
== Development ==<br />
<br />
== Running with docker / podman ==<br />
(experimental)<br />
<br />
How to run in docker:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
* Start the container:<br />
docker-compose up<br />
<br />
== Forwarding noise data ==<br />
How it is encoded in the sensor.community firmware:<br />
* Three values are sent in the JSON to sensor.community:<br />
** "noise_LAeq", value in dB(A)<br />
** "noise_LA_min", value in dB(A)<br />
** "noise_LA_max", value in dB(A)<br />
<br />
Values are read from the noise sensor as follows:<br />
* call to dnms_calculate_leq()<br />
* call to dnms_read_data_ready(&data_ready) returns 0 if OK and (data_ready != 0)<br />
* call to dnms_read_leq(&dnms_values) returns 0 if OK<br />
* firmware applies a "correction" by adding a fixed offset<br />
<br />
Measurement values are encoded as 32-bit units, interpreted as 32-bit floats.<br />
<br />
References:<br />
* DNMS is read at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3392<br />
* DNMS is formatted in the JSON at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3405<br />
* DNMS I2C code is at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/dnms_i2c.cpp</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Sensor-data-bridge&diff=32152Sensor-data-bridge2024-03-10T22:13:05Z<p>Bertrik Sikken: /* Installation */</p>
<hr />
<div>{{Project<br />
|Name=sensor-data-bridge<br />
|Picture=loraluftdatenforwarder.png<br />
|Omschrijving=Collects sensor data, forwards it to sensor.community/opensense/etc<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== What is this ==<br />
This is a companion project of [[LoraWanDustSensor]].<br />
<br />
It takes airborne particulate matter measurement data transferred through TheThingsNetwork and forwards it to online databases:<br />
* http://sensor.community (formerly Luftdaten), <br />
* http://opensensemap.org and <br />
* <s>https://cayenne.mydevices.com</s><br />
<br />
Project on Github: https://github.com/bertrik/sensor-data-bridge<br />
<br />
Unofficial sensor.community API documentation: https://api-sensor-community.bessarabov.com/<br />
<br />
=== Features ===<br />
* Picks up particulate matter measurement data received through TheThingsNetwork, using their "v3" infrastructure<br />
* Forwards measurement data to https://sensor.community<br />
* Forwards measurement data to https://opensensemap.org, you can configure the opensense-id by adding a device attribute in TheThingsNetwork console<br />
* Forwards measurement data to https://cayenne.mydevices.com, you configure the username/password/clientid by adding a device attribute in TheThingsNetwork console <br />
* Supports Cayenne payload format for the data encoding, a custom payload format for SPS30 data (includes particle counts)<br />
* Supports JSON payload format for the data encoding, you can specify in the config file which JSON fields are used<br />
* Handles particulate matter data (PM10, PM4.0, PM2.5, PM1.0), temperature, humidity, barometric pressure<br />
* Handles sound/noise data (LA EQ, and min/max value)<br />
* Can be run as a systemd service, so it automatically restarts in case the software would crash<br />
<br />
=== Next steps ===<br />
* add support for geolocation through a scan of surrounding WiFi access-points and a geolocation service (google, mozilla), see h<br />
* add support for NB-IOT modem with t-mobile backend, see my [[Sim7020]] project<br />
* add support for other backends, e.g. feinstaub-app?<br />
<br />
== Requirements ==<br />
You need the following:<br />
* a server that is always on and connected to the internet, can be Linux or Windows<br />
* a Java installation (<b>JDK</b> to compile), at least version 8<br />
* some configuration on TheThingsNetwork side<br />
* some configuration of my application (YAML file)<br />
<br />
== Compilation ==<br />
To compile the software:<br />
* clone the software from my github archive<br />
git clone https://github.com/bertrik/sensor-data-bridge.git<br />
* enter the application directory<br />
cd sensor-data-bridge<br />
* run the gradle script to build the software (Linux):<br />
./gradlew assemble<br />
or (Windows):<br />
gradlew assemble<br />
* the application zip & tar is now available in sensor-data-bridge/sensor-data-bridge/build/distributions<br />
<br />
To update to the latest version:<br />
* Update software from github archive:<br />
git pull<br />
* perform the last two steps above again<br />
<br />
== Installation ==<br />
<br />
<br />
=== run as docker container ===<br />
TODO<br />
<br />
<br />
=== installation from raw tar ===<br />
Unzip the distribution file somewhere on your system.<br />
I put it in my home directory, for example<br />
cd<br />
tar xvf code/sensor-data-bridge/sensor-data-bridge/build/distributions/sensor-data-bridge.tar<br />
<br />
== Configuration ==<br />
<br />
=== Node configuration ===<br />
The particulate matter measurement device needs to send data in the Cayenne format.<br />
I used the following conventions:<br />
* PM10 is encoded as analog value on channel 1<br />
* PM2.5 is encoded as analog value on channel 2<br />
* PM1.0 is encoded as analog value on channel 0 (optional)<br />
* PM4.0 is encoded as analog value on channel 4 (optional)<br />
* Temperature is encoded using standard Cayenne encoding (optional)<br />
* Humidity is encoded using standard Cayenne encoding (optional)<br />
* Barometric pressure is encoded using standard Cayenne encoding (optional)<br />
<br />
The SPS30 produces mass concentration data in 4 categories, particle count in 5 categories, plus particle size.<br />
Format:<br />
* 16-bit (big endian) PM1.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM2.5 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM4.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM10 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM0.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM1.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM2.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM4.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM10 number concentration (unit 1)<br />
* 16-bit (big endian) typical particle size (unit nm)<br />
<br />
A total of 20 bytes. This is sent on LoRaWAN port 30.<br />
Temperature and humidity is not encoded.<br />
<br />
In case your node uses a payload decoder in the TTN console, you can configure the sensor-data-bridge with the name of the JSON property:<br />
* 'path' is a pointer inside the decoded JSON payload that contains the value, e.g. "lc/avg"<br />
* 'item' is an internal id in the sensor-data-bridge, e.g. "PM10", see https://github.com/bertrik/sensor-data-bridge/blob/master/sensor-data-bridge/src/main/java/nl/bertriksikken/pm/ESensorItem.java<br />
<br />
=== TheThingsNetwork application/device configuration ===<br />
[[File:TtnEditApiKey.png|thumb|right|TTN API key rights]]<br />
<br />
You need to define an 'application' on TheTheThingsNetwork.<br />
<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
* You need an 'application', create a new one, or use an existing one<br />
* Within the application you need a 'device', so create a new one, or use an existing one:<br />
** Use OTAA, LoRaMac version 1.0.3<br />
** Enter the device EUI as displayed on the display<br />
** Use the application keys as specified in my [[LoraWanDustSensor]] page<br />
* You need an API key<br />
** Create this on the TTN console, grant individual rights as shown in the screenshot<br />
** NOTE: you have only one chance to copy this key somewhere, so copy/paste it locally to a text file or something<br />
<br />
=== Configuration ===<br />
To configure the application:<br />
* Start the application without a configuration file, this will create a default template, stop the application again<br />
cd sensor-data-bridge<br />
bin/sensor-data-bridge<br />
(ctrl-C)<br />
* Edit the configuration YAML file, example:<br />
<br />
<pre><br />
---<br />
ttn:<br />
mqtt_url: "tcp://eu1.cloud.thethings.network"<br />
identity_server_url: "https://eu1.cloud.thethings.network"<br />
identity_server_timeout: 20<br />
apps:<br />
- name: "particulatematter"<br />
key: "NNSXS......."<br />
encoding: "CAYENNE"<br />
senscom:<br />
url: "https://api.sensor.community"<br />
timeout: 20<br />
opensense:<br />
url: "https://api.opensensemap.org"<br />
timeout: 20<br />
</pre><br />
<br />
So:<br />
* enter the name of your application<br />
* enter the TTN API key you saved earlier<br />
* other defaults are probably OK<br />
<br />
=== Sensor.community ===<br />
TODO<br />
* Go to https://devices.sensor.community/ and log in<br />
* Register a node with id 'TTN-<device-EUI-as-shown-on-display>' (without the spaces or hyphens, e.g. 'TTN-0000547AF1BF713C')<br />
* Register it with the proper configuration, e.g. SDS011 with BME280<br />
* In the TTN console, add a device attribute with name 'senscom-id' and value 'TTN-<device-EUI-as-shown-on-display>'<br />
<br />
=== Opensensemap ===<br />
* Go to opensensemap.org and log in<br />
** Create an opensense node with the proper configuration<br />
** Copy the opensensenmap 'box id', a long hexadecimal string<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
** Add an attribute for the device, under 'General settings', name = 'opensense-id', value = boxid that you copied from opensensemap.org<br />
* The mapping from TTN-id to boxid is refreshed by the forwarder once an hour, so within an hour the forwarding to opensensemap.org starts<br />
<br />
== Development ==<br />
<br />
== Running with docker / podman ==<br />
(experimental)<br />
<br />
How to run in docker:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
* Start the container:<br />
docker-compose up<br />
<br />
== Forwarding noise data ==<br />
How it is encoded in the sensor.community firmware:<br />
* Three values are sent in the JSON to sensor.community:<br />
** "noise_LAeq", value in dB(A)<br />
** "noise_LA_min", value in dB(A)<br />
** "noise_LA_max", value in dB(A)<br />
<br />
Values are read from the noise sensor as follows:<br />
* call to dnms_calculate_leq()<br />
* call to dnms_read_data_ready(&data_ready) returns 0 if OK and (data_ready != 0)<br />
* call to dnms_read_leq(&dnms_values) returns 0 if OK<br />
* firmware applies a "correction" by adding a fixed offset<br />
<br />
Measurement values are encoded as 32-bit units, interpreted as 32-bit floats.<br />
<br />
References:<br />
* DNMS is read at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3392<br />
* DNMS is formatted in the JSON at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3405<br />
* DNMS I2C code is at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/dnms_i2c.cpp</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Sensor-data-bridge&diff=32126Sensor-data-bridge2024-02-22T16:07:39Z<p>Bertrik Sikken: /* Configuration */</p>
<hr />
<div>{{Project<br />
|Name=sensor-data-bridge<br />
|Picture=loraluftdatenforwarder.png<br />
|Omschrijving=Collects sensor data, forwards it to sensor.community/opensense/etc<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== What is this ==<br />
This is a companion project of [[LoraWanDustSensor]].<br />
<br />
It takes airborne particulate matter measurement data transferred through TheThingsNetwork and forwards it to online databases:<br />
* http://sensor.community (formerly Luftdaten), <br />
* http://opensensemap.org and <br />
* <s>https://cayenne.mydevices.com</s><br />
<br />
Project on Github: https://github.com/bertrik/sensor-data-bridge<br />
<br />
Unofficial sensor.community API documentation: https://api-sensor-community.bessarabov.com/<br />
<br />
=== Features ===<br />
* Picks up particulate matter measurement data received through TheThingsNetwork, using their "v3" infrastructure<br />
* Forwards measurement data to https://sensor.community<br />
* Forwards measurement data to https://opensensemap.org, you can configure the opensense-id by adding a device attribute in TheThingsNetwork console<br />
* Forwards measurement data to https://cayenne.mydevices.com, you configure the username/password/clientid by adding a device attribute in TheThingsNetwork console <br />
* Supports Cayenne payload format for the data encoding, a custom payload format for SPS30 data (includes particle counts)<br />
* Supports JSON payload format for the data encoding, you can specify in the config file which JSON fields are used<br />
* Handles particulate matter data (PM10, PM4.0, PM2.5, PM1.0), temperature, humidity, barometric pressure<br />
* Handles sound/noise data (LA EQ, and min/max value)<br />
* Can be run as a systemd service, so it automatically restarts in case the software would crash<br />
<br />
=== Next steps ===<br />
* add support for geolocation through a scan of surrounding WiFi access-points and a geolocation service (google, mozilla), see h<br />
* add support for NB-IOT modem with t-mobile backend, see my [[Sim7020]] project<br />
* add support for other backends, e.g. feinstaub-app?<br />
<br />
== Requirements ==<br />
You need the following:<br />
* a server that is always on and connected to the internet, can be Linux or Windows<br />
* a Java installation (<b>JDK</b> to compile), at least version 8<br />
* some configuration on TheThingsNetwork side<br />
* some configuration of my application (YAML file)<br />
<br />
== Compilation ==<br />
To compile the software:<br />
* clone the software from my github archive<br />
git clone https://github.com/bertrik/sensor-data-bridge.git<br />
* enter the application directory<br />
cd sensor-data-bridge<br />
* run the gradle script to build the software (Linux):<br />
./gradlew assemble<br />
or (Windows):<br />
gradlew assemble<br />
* the application zip & tar is now available in sensor-data-bridge/sensor-data-bridge/build/distributions<br />
<br />
To update to the latest version:<br />
* Update software from github archive:<br />
git pull<br />
* perform the last two steps above again<br />
<br />
== Installation ==<br />
<br />
=== installation for raw tar ===<br />
Unzip the distribution file somewhere on your system.<br />
I put it in my home directory, for example<br />
cd<br />
tar xvf code/sensor-data-bridge/sensor-data-bridge/build/distributions/sensor-data-bridge.tar<br />
<br />
=== run as docker container ===<br />
TODO<br />
<br />
== Configuration ==<br />
<br />
=== Node configuration ===<br />
The particulate matter measurement device needs to send data in the Cayenne format.<br />
I used the following conventions:<br />
* PM10 is encoded as analog value on channel 1<br />
* PM2.5 is encoded as analog value on channel 2<br />
* PM1.0 is encoded as analog value on channel 0 (optional)<br />
* PM4.0 is encoded as analog value on channel 4 (optional)<br />
* Temperature is encoded using standard Cayenne encoding (optional)<br />
* Humidity is encoded using standard Cayenne encoding (optional)<br />
* Barometric pressure is encoded using standard Cayenne encoding (optional)<br />
<br />
The SPS30 produces mass concentration data in 4 categories, particle count in 5 categories, plus particle size.<br />
Format:<br />
* 16-bit (big endian) PM1.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM2.5 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM4.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM10 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM0.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM1.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM2.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM4.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM10 number concentration (unit 1)<br />
* 16-bit (big endian) typical particle size (unit nm)<br />
<br />
A total of 20 bytes. This is sent on LoRaWAN port 30.<br />
Temperature and humidity is not encoded.<br />
<br />
In case your node uses a payload decoder in the TTN console, you can configure the sensor-data-bridge with the name of the JSON property:<br />
* 'path' is a pointer inside the decoded JSON payload that contains the value, e.g. "lc/avg"<br />
* 'item' is an internal id in the sensor-data-bridge, e.g. "PM10", see https://github.com/bertrik/sensor-data-bridge/blob/master/sensor-data-bridge/src/main/java/nl/bertriksikken/pm/ESensorItem.java<br />
<br />
=== TheThingsNetwork application/device configuration ===<br />
[[File:TtnEditApiKey.png|thumb|right|TTN API key rights]]<br />
<br />
You need to define an 'application' on TheTheThingsNetwork.<br />
<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
* You need an 'application', create a new one, or use an existing one<br />
* Within the application you need a 'device', so create a new one, or use an existing one:<br />
** Use OTAA, LoRaMac version 1.0.3<br />
** Enter the device EUI as displayed on the display<br />
** Use the application keys as specified in my [[LoraWanDustSensor]] page<br />
* You need an API key<br />
** Create this on the TTN console, grant individual rights as shown in the screenshot<br />
** NOTE: you have only one chance to copy this key somewhere, so copy/paste it locally to a text file or something<br />
<br />
=== Configuration ===<br />
To configure the application:<br />
* Start the application without a configuration file, this will create a default template, stop the application again<br />
cd sensor-data-bridge<br />
bin/sensor-data-bridge<br />
(ctrl-C)<br />
* Edit the configuration YAML file, example:<br />
<br />
<pre><br />
---<br />
ttn:<br />
mqtt_url: "tcp://eu1.cloud.thethings.network"<br />
identity_server_url: "https://eu1.cloud.thethings.network"<br />
identity_server_timeout: 20<br />
apps:<br />
- name: "particulatematter"<br />
key: "NNSXS......."<br />
encoding: "CAYENNE"<br />
senscom:<br />
url: "https://api.sensor.community"<br />
timeout: 20<br />
opensense:<br />
url: "https://api.opensensemap.org"<br />
timeout: 20<br />
</pre><br />
<br />
So:<br />
* enter the name of your application<br />
* enter the TTN API key you saved earlier<br />
* other defaults are probably OK<br />
<br />
=== Sensor.community ===<br />
TODO<br />
* Go to https://devices.sensor.community/ and log in<br />
* Register a node with id 'TTN-<device-EUI-as-shown-on-display>' (without the spaces or hyphens, e.g. 'TTN-0000547AF1BF713C')<br />
* Register it with the proper configuration, e.g. SDS011 with BME280<br />
* In the TTN console, add a device attribute with name 'senscom-id' and value 'TTN-<device-EUI-as-shown-on-display>'<br />
<br />
=== Opensensemap ===<br />
* Go to opensensemap.org and log in<br />
** Create an opensense node with the proper configuration<br />
** Copy the opensensenmap 'box id', a long hexadecimal string<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
** Add an attribute for the device, under 'General settings', name = 'opensense-id', value = boxid that you copied from opensensemap.org<br />
* The mapping from TTN-id to boxid is refreshed by the forwarder once an hour, so within an hour the forwarding to opensensemap.org starts<br />
<br />
== Development ==<br />
<br />
== Running with docker / podman ==<br />
(experimental)<br />
<br />
How to run in docker:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
* Start the container:<br />
docker-compose up<br />
<br />
== Forwarding noise data ==<br />
How it is encoded in the sensor.community firmware:<br />
* Three values are sent in the JSON to sensor.community:<br />
** "noise_LAeq", value in dB(A)<br />
** "noise_LA_min", value in dB(A)<br />
** "noise_LA_max", value in dB(A)<br />
<br />
Values are read from the noise sensor as follows:<br />
* call to dnms_calculate_leq()<br />
* call to dnms_read_data_ready(&data_ready) returns 0 if OK and (data_ready != 0)<br />
* call to dnms_read_leq(&dnms_values) returns 0 if OK<br />
* firmware applies a "correction" by adding a fixed offset<br />
<br />
Measurement values are encoded as 32-bit units, interpreted as 32-bit floats.<br />
<br />
References:<br />
* DNMS is read at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3392<br />
* DNMS is formatted in the JSON at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3405<br />
* DNMS I2C code is at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/dnms_i2c.cpp</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Sensor-data-bridge&diff=32094Sensor-data-bridge2024-02-12T13:05:33Z<p>Bertrik Sikken: /* Installation */</p>
<hr />
<div>{{Project<br />
|Name=sensor-data-bridge<br />
|Picture=loraluftdatenforwarder.png<br />
|Omschrijving=Collects sensor data, forwards it to sensor.community/opensense/etc<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== What is this ==<br />
This is a companion project of [[LoraWanDustSensor]].<br />
<br />
It takes airborne particulate matter measurement data transferred through TheThingsNetwork and forwards it to online databases:<br />
* http://sensor.community (formerly Luftdaten), <br />
* http://opensensemap.org and <br />
* <s>https://cayenne.mydevices.com</s><br />
<br />
Project on Github: https://github.com/bertrik/sensor-data-bridge<br />
<br />
Unofficial sensor.community API documentation: https://api-sensor-community.bessarabov.com/<br />
<br />
=== Features ===<br />
* Picks up particulate matter measurement data received through TheThingsNetwork, using their "v3" infrastructure<br />
* Forwards measurement data to https://sensor.community<br />
* Forwards measurement data to https://opensensemap.org, you can configure the opensense-id by adding a device attribute in TheThingsNetwork console<br />
* Forwards measurement data to https://cayenne.mydevices.com, you configure the username/password/clientid by adding a device attribute in TheThingsNetwork console <br />
* Supports Cayenne payload format for the data encoding, a custom payload format for SPS30 data (includes particle counts)<br />
* Supports JSON payload format for the data encoding, you can specify in the config file which JSON fields are used<br />
* Handles particulate matter data (PM10, PM4.0, PM2.5, PM1.0), temperature, humidity, barometric pressure<br />
* Handles sound/noise data (LA EQ, and min/max value)<br />
* Can be run as a systemd service, so it automatically restarts in case the software would crash<br />
<br />
=== Next steps ===<br />
* add support for geolocation through a scan of surrounding WiFi access-points and a geolocation service (google, mozilla), see h<br />
* add support for NB-IOT modem with t-mobile backend, see my [[Sim7020]] project<br />
* add support for other backends, e.g. feinstaub-app?<br />
<br />
== Requirements ==<br />
You need the following:<br />
* a server that is always on and connected to the internet, can be Linux or Windows<br />
* a Java installation (<b>JDK</b> to compile), at least version 8<br />
* some configuration on TheThingsNetwork side<br />
* some configuration of my application (YAML file)<br />
<br />
== Compilation ==<br />
To compile the software:<br />
* clone the software from my github archive<br />
git clone https://github.com/bertrik/sensor-data-bridge.git<br />
* enter the application directory<br />
cd sensor-data-bridge<br />
* run the gradle script to build the software (Linux):<br />
./gradlew assemble<br />
or (Windows):<br />
gradlew assemble<br />
* the application zip & tar is now available in sensor-data-bridge/sensor-data-bridge/build/distributions<br />
<br />
To update to the latest version:<br />
* Update software from github archive:<br />
git pull<br />
* perform the last two steps above again<br />
<br />
== Installation ==<br />
<br />
=== installation for raw tar ===<br />
Unzip the distribution file somewhere on your system.<br />
I put it in my home directory, for example<br />
cd<br />
tar xvf code/sensor-data-bridge/sensor-data-bridge/build/distributions/sensor-data-bridge.tar<br />
<br />
=== run as docker container ===<br />
TODO<br />
<br />
== Configuration ==<br />
<br />
=== Node configuration ===<br />
The particulate matter measurement device needs to send data in the Cayenne format.<br />
I used the following conventions:<br />
* PM10 is encoded as analog value on channel 1<br />
* PM2.5 is encoded as analog value on channel 2<br />
* PM1.0 is encoded as analog value on channel 0 (optional)<br />
* PM4.0 is encoded as analog value on channel 4 (optional)<br />
* Temperature is encoded using standard Cayenne encoding (optional)<br />
* Humidity is encoded using standard Cayenne encoding (optional)<br />
* Barometric pressure is encoded using standard Cayenne encoding (optional)<br />
<br />
The SPS30 produces mass concentration data in 4 categories, particle count in 5 categories, plus particle size.<br />
Format:<br />
* 16-bit (big endian) PM1.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM2.5 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM4.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM10 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM0.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM1.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM2.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM4.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM10 number concentration (unit 1)<br />
* 16-bit (big endian) typical particle size (unit nm)<br />
<br />
A total of 20 bytes. This is sent on LoRaWAN port 30.<br />
Temperature and humidity is not encoded.<br />
<br />
In case your node uses a payload decoder in the TTN console, you can configure the sensor-data-bridge with the name of the JSON property:<br />
* 'path' is a pointer inside the decoded JSON payload that contains the value, e.g. "lc/avg"<br />
* 'item' is an internal id in the sensor-data-bridge, e.g. "PM10", see https://github.com/bertrik/sensor-data-bridge/blob/master/sensor-data-bridge/src/main/java/nl/bertriksikken/pm/ESensorItem.java<br />
<br />
=== TheThingsNetwork application/device configuration ===<br />
[[File:TtnEditApiKey.png|thumb|right|TTN API key rights]]<br />
<br />
You need to define an 'application' on TheTheThingsNetwork.<br />
<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
* You need an 'application', create a new one, or use an existing one<br />
* Within the application you need a 'device', so create a new one, or use an existing one:<br />
** Use OTAA, LoRaMac version 1.0.3<br />
** Enter the device EUI as displayed on the display<br />
** Use the application keys as specified in my [[LoraWanDustSensor]] page<br />
* You need an API key<br />
** Create this on the TTN console, grant individual rights as shown in the screenshot<br />
** NOTE: you have only one chance to copy this key somewhere, so copy/paste it locally to a text file or something<br />
<br />
=== Configuration ===<br />
To configure the application:<br />
* Start the application without a configuration file, this will create a default template, stop the application again<br />
cd sensor-data-bridge<br />
bin/sensor-data-bridge<br />
(ctrl-C)<br />
* Edit the configuration YAML file, example:<br />
<br />
<pre><br />
---<br />
ttn:<br />
mqtt_url: "tcp://eu1.cloud.thethings.network"<br />
identity_server_url: "https://eu1.cloud.thethings.network"<br />
identity_server_timeout: 20<br />
apps:<br />
- name: "particulatematter"<br />
key: "NNSXS......."<br />
encoding: "CAYENNE"<br />
senscom:<br />
url: "https://api.sensor.community"<br />
timeout: 20<br />
opensense:<br />
url: "https://api.opensensemap.org"<br />
timeout: 20<br />
</pre><br />
<br />
So:<br />
* enter the name of your application<br />
* enter the TTN API key you saved earlier<br />
* other defaults are probably OK<br />
<br />
=== Sensor.community ===<br />
TODO<br />
* Go to https://devices.sensor.community/ and log in<br />
* Register a node with id 'TTN-<device-EUI-as-shown-on-display>' (without the spaces or hyphens, e.g. 'TTN-0000547AF1BF713C')<br />
* Register it with the proper configuration, e.g. SDS011 with BME280<br />
* In the TTN console, add a device attribute with name 'senscom-id' and value 'TTN-<device-EUI-as-shown-on-display>'<br />
<br />
=== Opensensemap ===<br />
* Go to opensensemap.org and log in<br />
** Create an opensense node with the proper configuration<br />
** Copy the opensensenmap 'box id', a long hexadecimal string<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
** Add an attribute for the device, under 'General settings', name = 'opensense-id', value = boxid that you copied from opensensemap.org<br />
* The mapping from TTN-id to boxid is refreshed by the forwarder once an hour, so within an hour the forwarding to opensensemap.org starts<br />
<br />
=== Cayenne myDevices ===<br />
* Go to https://cayenne.mydevices.com/ and log in<br />
** Add a new node, TODO<br />
* Go to TTN console and log in<br />
** Add attributes for the device, under 'General settings'<br />
*** attribute name = 'mydevices-username', value = MQTT username from cayenne mydevices dashboard<br />
*** attribute name = 'mydevices-password', value = MQTT password from cayenne mydevices dashboard<br />
*** attribute name = 'mydevices-clientid', value = Client ID from cayenne mydevices dashboard<br />
<br />
<nowiki>Insert non-formatted text here</nowiki>== Development ==<br />
<br />
== Running with docker / podman ==<br />
(experimental)<br />
<br />
How to run in docker:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
* Start the container:<br />
docker-compose up<br />
<br />
== Forwarding noise data ==<br />
How it is encoded in the sensor.community firmware:<br />
* Three values are sent in the JSON to sensor.community:<br />
** "noise_LAeq", value in dB(A)<br />
** "noise_LA_min", value in dB(A)<br />
** "noise_LA_max", value in dB(A)<br />
<br />
Values are read from the noise sensor as follows:<br />
* call to dnms_calculate_leq()<br />
* call to dnms_read_data_ready(&data_ready) returns 0 if OK and (data_ready != 0)<br />
* call to dnms_read_leq(&dnms_values) returns 0 if OK<br />
* firmware applies a "correction" by adding a fixed offset<br />
<br />
Measurement values are encoded as 32-bit units, interpreted as 32-bit floats.<br />
<br />
References:<br />
* DNMS is read at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3392<br />
* DNMS is formatted in the JSON at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3405<br />
* DNMS I2C code is at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/dnms_i2c.cpp</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Sensor-data-bridge&diff=32093Sensor-data-bridge2024-02-12T13:04:38Z<p>Bertrik Sikken: /* What is this */</p>
<hr />
<div>{{Project<br />
|Name=sensor-data-bridge<br />
|Picture=loraluftdatenforwarder.png<br />
|Omschrijving=Collects sensor data, forwards it to sensor.community/opensense/etc<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== What is this ==<br />
This is a companion project of [[LoraWanDustSensor]].<br />
<br />
It takes airborne particulate matter measurement data transferred through TheThingsNetwork and forwards it to online databases:<br />
* http://sensor.community (formerly Luftdaten), <br />
* http://opensensemap.org and <br />
* <s>https://cayenne.mydevices.com</s><br />
<br />
Project on Github: https://github.com/bertrik/sensor-data-bridge<br />
<br />
Unofficial sensor.community API documentation: https://api-sensor-community.bessarabov.com/<br />
<br />
=== Features ===<br />
* Picks up particulate matter measurement data received through TheThingsNetwork, using their "v3" infrastructure<br />
* Forwards measurement data to https://sensor.community<br />
* Forwards measurement data to https://opensensemap.org, you can configure the opensense-id by adding a device attribute in TheThingsNetwork console<br />
* Forwards measurement data to https://cayenne.mydevices.com, you configure the username/password/clientid by adding a device attribute in TheThingsNetwork console <br />
* Supports Cayenne payload format for the data encoding, a custom payload format for SPS30 data (includes particle counts)<br />
* Supports JSON payload format for the data encoding, you can specify in the config file which JSON fields are used<br />
* Handles particulate matter data (PM10, PM4.0, PM2.5, PM1.0), temperature, humidity, barometric pressure<br />
* Handles sound/noise data (LA EQ, and min/max value)<br />
* Can be run as a systemd service, so it automatically restarts in case the software would crash<br />
<br />
=== Next steps ===<br />
* add support for geolocation through a scan of surrounding WiFi access-points and a geolocation service (google, mozilla), see h<br />
* add support for NB-IOT modem with t-mobile backend, see my [[Sim7020]] project<br />
* add support for other backends, e.g. feinstaub-app?<br />
<br />
== Requirements ==<br />
You need the following:<br />
* a server that is always on and connected to the internet, can be Linux or Windows<br />
* a Java installation (<b>JDK</b> to compile), at least version 8<br />
* some configuration on TheThingsNetwork side<br />
* some configuration of my application (YAML file)<br />
<br />
== Compilation ==<br />
To compile the software:<br />
* clone the software from my github archive<br />
git clone https://github.com/bertrik/sensor-data-bridge.git<br />
* enter the application directory<br />
cd sensor-data-bridge<br />
* run the gradle script to build the software (Linux):<br />
./gradlew assemble<br />
or (Windows):<br />
gradlew assemble<br />
* the application zip & tar is now available in sensor-data-bridge/sensor-data-bridge/build/distributions<br />
<br />
To update to the latest version:<br />
* Update software from github archive:<br />
git pull<br />
* perform the last two steps above again<br />
<br />
== Installation ==<br />
Unzip the distribution file somewhere on your system.<br />
I put it in my home directory, for example<br />
cd<br />
tar xvf code/sensor-data-bridge/sensor-data-bridge/build/distributions/sensor-data-bridge.tar<br />
<br />
== Configuration ==<br />
<br />
=== Node configuration ===<br />
The particulate matter measurement device needs to send data in the Cayenne format.<br />
I used the following conventions:<br />
* PM10 is encoded as analog value on channel 1<br />
* PM2.5 is encoded as analog value on channel 2<br />
* PM1.0 is encoded as analog value on channel 0 (optional)<br />
* PM4.0 is encoded as analog value on channel 4 (optional)<br />
* Temperature is encoded using standard Cayenne encoding (optional)<br />
* Humidity is encoded using standard Cayenne encoding (optional)<br />
* Barometric pressure is encoded using standard Cayenne encoding (optional)<br />
<br />
The SPS30 produces mass concentration data in 4 categories, particle count in 5 categories, plus particle size.<br />
Format:<br />
* 16-bit (big endian) PM1.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM2.5 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM4.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM10 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM0.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM1.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM2.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM4.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM10 number concentration (unit 1)<br />
* 16-bit (big endian) typical particle size (unit nm)<br />
<br />
A total of 20 bytes. This is sent on LoRaWAN port 30.<br />
Temperature and humidity is not encoded.<br />
<br />
In case your node uses a payload decoder in the TTN console, you can configure the sensor-data-bridge with the name of the JSON property:<br />
* 'path' is a pointer inside the decoded JSON payload that contains the value, e.g. "lc/avg"<br />
* 'item' is an internal id in the sensor-data-bridge, e.g. "PM10", see https://github.com/bertrik/sensor-data-bridge/blob/master/sensor-data-bridge/src/main/java/nl/bertriksikken/pm/ESensorItem.java<br />
<br />
=== TheThingsNetwork application/device configuration ===<br />
[[File:TtnEditApiKey.png|thumb|right|TTN API key rights]]<br />
<br />
You need to define an 'application' on TheTheThingsNetwork.<br />
<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
* You need an 'application', create a new one, or use an existing one<br />
* Within the application you need a 'device', so create a new one, or use an existing one:<br />
** Use OTAA, LoRaMac version 1.0.3<br />
** Enter the device EUI as displayed on the display<br />
** Use the application keys as specified in my [[LoraWanDustSensor]] page<br />
* You need an API key<br />
** Create this on the TTN console, grant individual rights as shown in the screenshot<br />
** NOTE: you have only one chance to copy this key somewhere, so copy/paste it locally to a text file or something<br />
<br />
=== Configuration ===<br />
To configure the application:<br />
* Start the application without a configuration file, this will create a default template, stop the application again<br />
cd sensor-data-bridge<br />
bin/sensor-data-bridge<br />
(ctrl-C)<br />
* Edit the configuration YAML file, example:<br />
<br />
<pre><br />
---<br />
ttn:<br />
mqtt_url: "tcp://eu1.cloud.thethings.network"<br />
identity_server_url: "https://eu1.cloud.thethings.network"<br />
identity_server_timeout: 20<br />
apps:<br />
- name: "particulatematter"<br />
key: "NNSXS......."<br />
encoding: "CAYENNE"<br />
senscom:<br />
url: "https://api.sensor.community"<br />
timeout: 20<br />
opensense:<br />
url: "https://api.opensensemap.org"<br />
timeout: 20<br />
</pre><br />
<br />
So:<br />
* enter the name of your application<br />
* enter the TTN API key you saved earlier<br />
* other defaults are probably OK<br />
<br />
=== Sensor.community ===<br />
TODO<br />
* Go to https://devices.sensor.community/ and log in<br />
* Register a node with id 'TTN-<device-EUI-as-shown-on-display>' (without the spaces or hyphens, e.g. 'TTN-0000547AF1BF713C')<br />
* Register it with the proper configuration, e.g. SDS011 with BME280<br />
* In the TTN console, add a device attribute with name 'senscom-id' and value 'TTN-<device-EUI-as-shown-on-display>'<br />
<br />
=== Opensensemap ===<br />
* Go to opensensemap.org and log in<br />
** Create an opensense node with the proper configuration<br />
** Copy the opensensenmap 'box id', a long hexadecimal string<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
** Add an attribute for the device, under 'General settings', name = 'opensense-id', value = boxid that you copied from opensensemap.org<br />
* The mapping from TTN-id to boxid is refreshed by the forwarder once an hour, so within an hour the forwarding to opensensemap.org starts<br />
<br />
=== Cayenne myDevices ===<br />
* Go to https://cayenne.mydevices.com/ and log in<br />
** Add a new node, TODO<br />
* Go to TTN console and log in<br />
** Add attributes for the device, under 'General settings'<br />
*** attribute name = 'mydevices-username', value = MQTT username from cayenne mydevices dashboard<br />
*** attribute name = 'mydevices-password', value = MQTT password from cayenne mydevices dashboard<br />
*** attribute name = 'mydevices-clientid', value = Client ID from cayenne mydevices dashboard<br />
<br />
<nowiki>Insert non-formatted text here</nowiki>== Development ==<br />
<br />
== Running with docker / podman ==<br />
(experimental)<br />
<br />
How to run in docker:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
* Start the container:<br />
docker-compose up<br />
<br />
== Forwarding noise data ==<br />
How it is encoded in the sensor.community firmware:<br />
* Three values are sent in the JSON to sensor.community:<br />
** "noise_LAeq", value in dB(A)<br />
** "noise_LA_min", value in dB(A)<br />
** "noise_LA_max", value in dB(A)<br />
<br />
Values are read from the noise sensor as follows:<br />
* call to dnms_calculate_leq()<br />
* call to dnms_read_data_ready(&data_ready) returns 0 if OK and (data_ready != 0)<br />
* call to dnms_read_leq(&dnms_values) returns 0 if OK<br />
* firmware applies a "correction" by adding a fixed offset<br />
<br />
Measurement values are encoded as 32-bit units, interpreted as 32-bit floats.<br />
<br />
References:<br />
* DNMS is read at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3392<br />
* DNMS is formatted in the JSON at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3405<br />
* DNMS I2C code is at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/dnms_i2c.cpp</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Sensor-data-bridge&diff=32092Sensor-data-bridge2024-02-12T12:49:14Z<p>Bertrik Sikken: /* What is this */</p>
<hr />
<div>{{Project<br />
|Name=sensor-data-bridge<br />
|Picture=loraluftdatenforwarder.png<br />
|Omschrijving=Collects sensor data, forwards it to sensor.community/opensense/etc<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== What is this ==<br />
This is a companion project of [[LoraWanDustSensor]].<br />
<br />
It takes airborne particulate matter measurement data transferred through TheThingsNetwork and forwards it to online databases:<br />
* http://sensor.community (formerly Luftdaten), <br />
* http://opensensemap.org and <br />
* <s>https://cayenne.mydevices.com</s><br />
<br />
Project on Github: https://github.com/bertrik/sensor-data-bridge<br />
<br />
=== Features ===<br />
* Picks up particulate matter measurement data received through TheThingsNetwork, using their "v3" infrastructure<br />
* Forwards measurement data to https://sensor.community<br />
* Forwards measurement data to https://opensensemap.org, you can configure the opensense-id by adding a device attribute in TheThingsNetwork console<br />
* Forwards measurement data to https://cayenne.mydevices.com, you configure the username/password/clientid by adding a device attribute in TheThingsNetwork console <br />
* Supports Cayenne payload format for the data encoding, a custom payload format for SPS30 data (includes particle counts)<br />
* Supports JSON payload format for the data encoding, you can specify in the config file which JSON fields are used<br />
* Handles particulate matter data (PM10, PM4.0, PM2.5, PM1.0), temperature, humidity, barometric pressure<br />
* Handles sound/noise data (LA EQ, and min/max value)<br />
* Can be run as a systemd service, so it automatically restarts in case the software would crash<br />
<br />
=== Next steps ===<br />
* add support for geolocation through a scan of surrounding WiFi access-points and a geolocation service (google, mozilla), see h<br />
* add support for NB-IOT modem with t-mobile backend, see my [[Sim7020]] project<br />
* add support for other backends, e.g. feinstaub-app?<br />
<br />
== Requirements ==<br />
You need the following:<br />
* a server that is always on and connected to the internet, can be Linux or Windows<br />
* a Java installation (<b>JDK</b> to compile), at least version 8<br />
* some configuration on TheThingsNetwork side<br />
* some configuration of my application (YAML file)<br />
<br />
== Compilation ==<br />
To compile the software:<br />
* clone the software from my github archive<br />
git clone https://github.com/bertrik/sensor-data-bridge.git<br />
* enter the application directory<br />
cd sensor-data-bridge<br />
* run the gradle script to build the software (Linux):<br />
./gradlew assemble<br />
or (Windows):<br />
gradlew assemble<br />
* the application zip & tar is now available in sensor-data-bridge/sensor-data-bridge/build/distributions<br />
<br />
To update to the latest version:<br />
* Update software from github archive:<br />
git pull<br />
* perform the last two steps above again<br />
<br />
== Installation ==<br />
Unzip the distribution file somewhere on your system.<br />
I put it in my home directory, for example<br />
cd<br />
tar xvf code/sensor-data-bridge/sensor-data-bridge/build/distributions/sensor-data-bridge.tar<br />
<br />
== Configuration ==<br />
<br />
=== Node configuration ===<br />
The particulate matter measurement device needs to send data in the Cayenne format.<br />
I used the following conventions:<br />
* PM10 is encoded as analog value on channel 1<br />
* PM2.5 is encoded as analog value on channel 2<br />
* PM1.0 is encoded as analog value on channel 0 (optional)<br />
* PM4.0 is encoded as analog value on channel 4 (optional)<br />
* Temperature is encoded using standard Cayenne encoding (optional)<br />
* Humidity is encoded using standard Cayenne encoding (optional)<br />
* Barometric pressure is encoded using standard Cayenne encoding (optional)<br />
<br />
The SPS30 produces mass concentration data in 4 categories, particle count in 5 categories, plus particle size.<br />
Format:<br />
* 16-bit (big endian) PM1.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM2.5 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM4.0 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM10 mass concentration (unit 0.1)<br />
* 16-bit (big endian) PM0.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM1.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM2.5 number concentration (unit 1)<br />
* 16-bit (big endian) PM4.0 number concentration (unit 1)<br />
* 16-bit (big endian) PM10 number concentration (unit 1)<br />
* 16-bit (big endian) typical particle size (unit nm)<br />
<br />
A total of 20 bytes. This is sent on LoRaWAN port 30.<br />
Temperature and humidity is not encoded.<br />
<br />
In case your node uses a payload decoder in the TTN console, you can configure the sensor-data-bridge with the name of the JSON property:<br />
* 'path' is a pointer inside the decoded JSON payload that contains the value, e.g. "lc/avg"<br />
* 'item' is an internal id in the sensor-data-bridge, e.g. "PM10", see https://github.com/bertrik/sensor-data-bridge/blob/master/sensor-data-bridge/src/main/java/nl/bertriksikken/pm/ESensorItem.java<br />
<br />
=== TheThingsNetwork application/device configuration ===<br />
[[File:TtnEditApiKey.png|thumb|right|TTN API key rights]]<br />
<br />
You need to define an 'application' on TheTheThingsNetwork.<br />
<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
* You need an 'application', create a new one, or use an existing one<br />
* Within the application you need a 'device', so create a new one, or use an existing one:<br />
** Use OTAA, LoRaMac version 1.0.3<br />
** Enter the device EUI as displayed on the display<br />
** Use the application keys as specified in my [[LoraWanDustSensor]] page<br />
* You need an API key<br />
** Create this on the TTN console, grant individual rights as shown in the screenshot<br />
** NOTE: you have only one chance to copy this key somewhere, so copy/paste it locally to a text file or something<br />
<br />
=== Configuration ===<br />
To configure the application:<br />
* Start the application without a configuration file, this will create a default template, stop the application again<br />
cd sensor-data-bridge<br />
bin/sensor-data-bridge<br />
(ctrl-C)<br />
* Edit the configuration YAML file, example:<br />
<br />
<pre><br />
---<br />
ttn:<br />
mqtt_url: "tcp://eu1.cloud.thethings.network"<br />
identity_server_url: "https://eu1.cloud.thethings.network"<br />
identity_server_timeout: 20<br />
apps:<br />
- name: "particulatematter"<br />
key: "NNSXS......."<br />
encoding: "CAYENNE"<br />
senscom:<br />
url: "https://api.sensor.community"<br />
timeout: 20<br />
opensense:<br />
url: "https://api.opensensemap.org"<br />
timeout: 20<br />
</pre><br />
<br />
So:<br />
* enter the name of your application<br />
* enter the TTN API key you saved earlier<br />
* other defaults are probably OK<br />
<br />
=== Sensor.community ===<br />
TODO<br />
* Go to https://devices.sensor.community/ and log in<br />
* Register a node with id 'TTN-<device-EUI-as-shown-on-display>' (without the spaces or hyphens, e.g. 'TTN-0000547AF1BF713C')<br />
* Register it with the proper configuration, e.g. SDS011 with BME280<br />
* In the TTN console, add a device attribute with name 'senscom-id' and value 'TTN-<device-EUI-as-shown-on-display>'<br />
<br />
=== Opensensemap ===<br />
* Go to opensensemap.org and log in<br />
** Create an opensense node with the proper configuration<br />
** Copy the opensensenmap 'box id', a long hexadecimal string<br />
* Go the TTN console: https://console.cloud.thethings.network/ and log in<br />
** Add an attribute for the device, under 'General settings', name = 'opensense-id', value = boxid that you copied from opensensemap.org<br />
* The mapping from TTN-id to boxid is refreshed by the forwarder once an hour, so within an hour the forwarding to opensensemap.org starts<br />
<br />
=== Cayenne myDevices ===<br />
* Go to https://cayenne.mydevices.com/ and log in<br />
** Add a new node, TODO<br />
* Go to TTN console and log in<br />
** Add attributes for the device, under 'General settings'<br />
*** attribute name = 'mydevices-username', value = MQTT username from cayenne mydevices dashboard<br />
*** attribute name = 'mydevices-password', value = MQTT password from cayenne mydevices dashboard<br />
*** attribute name = 'mydevices-clientid', value = Client ID from cayenne mydevices dashboard<br />
<br />
<nowiki>Insert non-formatted text here</nowiki>== Development ==<br />
<br />
== Running with docker / podman ==<br />
(experimental)<br />
<br />
How to run in docker:<br />
* Install docker and docker-compose and add your user account to the 'docker' group (Linux):<br />
sudo apt install docker-ce docker-compose<br />
sudo usermod -aG docker <username><br />
* Get the code from github:<br />
git clone https://github.com/bertrik/sensor-data-bridge<br />
* Enter the 'docker' directory and pull the docker image from github:<br />
cd sensor-data-bridge<br />
cd docker<br />
docker-compose pull<br />
* Edit the config files with your own settings:<br />
vi sensor-data-bridge.yaml<br />
* Start the container:<br />
docker-compose up<br />
<br />
== Forwarding noise data ==<br />
How it is encoded in the sensor.community firmware:<br />
* Three values are sent in the JSON to sensor.community:<br />
** "noise_LAeq", value in dB(A)<br />
** "noise_LA_min", value in dB(A)<br />
** "noise_LA_max", value in dB(A)<br />
<br />
Values are read from the noise sensor as follows:<br />
* call to dnms_calculate_leq()<br />
* call to dnms_read_data_ready(&data_ready) returns 0 if OK and (data_ready != 0)<br />
* call to dnms_read_leq(&dnms_values) returns 0 if OK<br />
* firmware applies a "correction" by adding a fixed offset<br />
<br />
Measurement values are encoded as 32-bit units, interpreted as 32-bit floats.<br />
<br />
References:<br />
* DNMS is read at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3392<br />
* DNMS is formatted in the JSON at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/airrohr-firmware.ino#L3405<br />
* DNMS I2C code is at https://github.com/opendata-stuttgart/sensors-software/blob/beta/airrohr-firmware/dnms_i2c.cpp</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=User:Bertrik_Sikken&diff=31950User:Bertrik Sikken2024-01-03T09:01:39Z<p>Bertrik Sikken: /* ribbon tweeter for bat audio */</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 (future)<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: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 />
=== 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 />
=== 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 />
https://nl.aliexpress.com/item/1005002565880660.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/index.php?title=User:Bertrik_Sikken&diff=31947User:Bertrik Sikken2024-01-01T20:19:21Z<p>Bertrik Sikken: /* Display of current electricity usage */</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 (future)<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: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 />
=== 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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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/index.php?title=User:Bertrik_Sikken&diff=31897User:Bertrik Sikken2023-11-30T16:46:19Z<p>Bertrik Sikken: /* Stookalert */</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 (future)<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: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 />
=== 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 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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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/index.php?title=User:Bertrik_Sikken&diff=31896User:Bertrik Sikken2023-11-30T12:28:30Z<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<br />
* energy-related stuff, visualisation<br />
* citizen science, particulate matter measurement, noise (future)<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: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 />
=== 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 />
<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 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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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/index.php?title=User:Bertrik_Sikken&diff=31858User:Bertrik Sikken2023-11-26T13:15:26Z<p>Bertrik Sikken: /* Display of current electricity usage */</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 (future)<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: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 />
=== 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 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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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/index.php?title=User:Bertrik_Sikken&diff=31856User:Bertrik Sikken2023-11-26T11:40:16Z<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<br />
* energy-related stuff, visualisation<br />
* citizen science, particulate matter measurement, noise (future)<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: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 />
=== 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 at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl 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 />
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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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/index.php?title=PowerLight&diff=31852PowerLight2023-11-23T09:12:39Z<p>Bertrik Sikken: /* Backend */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. The sum of the biomass and coal numbers at CO2monitor equal exactly the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning some fraction of the ENTSO-E hard-coal number to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
Some data from CBS on energy use for electricity production in 2022: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/80030NED/table?fromstatweb<br />
* total energy from coal: 53315 TJ<br />
* total energy from biomass: 34798 TJ<br />
This means a ratio of 39.5% biomass vs (biomass + coal), not exactly the CO2monitor number, but on the same order<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details (every 15 minutes) about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows in/out the dutch natural gas system, units are (MWh/day)<br />
<br />
Returns JSON-structures like:<br />
<pre>{<br />
"time": 1700728200,<br />
"datetime": "2023-11-23T09:30:00+01:00",<br />
"total": 13552,<br />
"mix": [ <br />
{ "id": "solar", "power": 1232, "color": "#FFFF00"}, <br />
{ "id": "wind onshore", "power": 4241, "color": "#0000FF" }, <br />
{ "id": "wind offshore", "power": 2963, "color": "#0000FF" }, <br />
{ "id": "fossil gas", "power": 2264, "color": "#FF0000" }, <br />
{ "id": "fossil coal", "power": 2051, "color": "#FF0000" }, <br />
{ "id": "nuclear", "power": 483, "color": "#00FF00" }, <br />
{ "id": "waste", "power": 70, "color": "#FF00FF" }, <br />
{ "id": "other", "power": 248, "color": "#FF00FF" } <br />
]<br />
}</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* dateime is ta user-readable time stamp, in dutch local time + offset<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
Interesting links:<br />
* https://hackaday.io/project/193697-octoclock-and-old-school-energy-meter<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=PowerLight&diff=31851PowerLight2023-11-23T09:09:44Z<p>Bertrik Sikken: /* Backend */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. The sum of the biomass and coal numbers at CO2monitor equal exactly the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning some fraction of the ENTSO-E hard-coal number to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
Some data from CBS on energy use for electricity production in 2022: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/80030NED/table?fromstatweb<br />
* total energy from coal: 53315 TJ<br />
* total energy from biomass: 34798 TJ<br />
This means a ratio of 39.5% biomass vs (biomass + coal), not exactly the CO2monitor number, but on the same order<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details (every 15 minutes) about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows in/out the dutch natural gas system, units are (MWh/day)<br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"datetime" : "2023-11-23T09:30:00+01:00",<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* dateime is ta user-readable time stamp, in dutch local time + offset<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
Interesting links:<br />
* https://hackaday.io/project/193697-octoclock-and-old-school-energy-meter<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=PowerLight&diff=31850PowerLight2023-11-23T09:08:31Z<p>Bertrik Sikken: /* Backend */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. The sum of the biomass and coal numbers at CO2monitor equal exactly the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning some fraction of the ENTSO-E hard-coal number to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
Some data from CBS on energy use for electricity production in 2022: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/80030NED/table?fromstatweb<br />
* total energy from coal: 53315 TJ<br />
* total energy from biomass: 34798 TJ<br />
This means a ratio of 39.5% biomass vs (biomass + coal), not exactly the CO2monitor number, but on the same order<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details (every 15 minutes) about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows in/out the dutch natural gas system, units are (MWh/day)<br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
Interesting links:<br />
* https://hackaday.io/project/193697-octoclock-and-old-school-energy-meter<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=PowerLight&diff=31849PowerLight2023-11-22T12:31:15Z<p>Bertrik Sikken: /* LED ring price clock */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. The sum of the biomass and coal numbers at CO2monitor equal exactly the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning some fraction of the ENTSO-E hard-coal number to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
Some data from CBS on energy use for electricity production in 2022: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/80030NED/table?fromstatweb<br />
* total energy from coal: 53315 TJ<br />
* total energy from biomass: 34798 TJ<br />
This means a ratio of 39.5% biomass vs (biomass + coal), not exactly the CO2monitor number, but on the same order<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows (MWh/day) in/out the dutch natural gas system <br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
Interesting links:<br />
* https://hackaday.io/project/193697-octoclock-and-old-school-energy-meter<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=PowerLight&diff=31841PowerLight2023-11-19T23:16:10Z<p>Bertrik Sikken: /* Data model behind CO2monitor.nl */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. The sum of the biomass and coal numbers at CO2monitor equal exactly the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning some fraction of the ENTSO-E hard-coal number to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
Some data from CBS on energy use for electricity production in 2022: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/80030NED/table?fromstatweb<br />
* total energy from coal: 53315 TJ<br />
* total energy from biomass: 34798 TJ<br />
This means a ratio of 39.5% biomass vs (biomass + coal), not exactly the CO2monitor number, but on the same order<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows (MWh/day) in/out the dutch natural gas system <br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=PowerLight&diff=31840PowerLight2023-11-19T23:13:15Z<p>Bertrik Sikken: /* Data model behind CO2monitor.nl */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. Biomass + coal at CO2monitor is exactly equal to the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning a fixed fraction of the hard coal reported by ENTSO-E to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
Some data from CBS on energy use for electricity production in 2022: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/80030NED/table?fromstatweb<br />
* total energy from coal: 53315 TJ<br />
* total energy from biomass: 34798 TJ<br />
This means a ratio of 39.5% biomass vs (biomass + coal), not exactly the CO2monitor number, but on the same order<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows (MWh/day) in/out the dutch natural gas system <br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=PowerLight&diff=31839PowerLight2023-11-19T23:12:35Z<p>Bertrik Sikken: /* Data model behind CO2monitor.nl */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. Biomass + coal at CO2monitor is exactly equal to the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning a fixed fraction of the hard coal reported by ENTSO-E to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
Some data from CBS on energy use for electricity production in 2022: https://opendata.cbs.nl/statline/#/CBS/nl/dataset/80030NED/table?fromstatweb<br />
* total energy from coal: 53315 TJ<br />
* total energy from biomass: 34798 TJ<br />
This means a ratio of 39.5% biomass vs (biomass + coal)<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows (MWh/day) in/out the dutch natural gas system <br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=User:Bertrik_Sikken&diff=31837User:Bertrik Sikken2023-11-18T13:43:50Z<p>Bertrik Sikken: /* GPS repeater */</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 (future)<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: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 />
=== 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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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/index.php?title=User:Bertrik_Sikken&diff=31836User:Bertrik Sikken2023-11-18T13:43:22Z<p>Bertrik Sikken: /* Blood pressure meter hacking */</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 (future)<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: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 />
=== 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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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 />
=== GPS repeater ===<br />
This idea is about experimenting with a cheap GPS repeater built out of an "active" GPS antenna.<br />
<br />
The problem this solves is that often indoors you have no GPS reception, but you like to have some signal to experiment with (e.g. a LoRa tracker).<br />
<br />
Plan:<br />
* get a cheap active GPS antenna from AliExpress (some as cheap as E2,- !), most just mention one frequency (1575.42 MHz)<br />
* get a bias-T circuit to feed it the supply voltage (e.g. from a KOPPLA) and pass the RF signal onto an indoor antenna<br />
* the indoor antenna may be as simple as a 1/4 wave coax dipole: center conductor sticking up (about 47 mm), coax shielding is divided into 3 of 4 ground radials sticking sideways<br />
* build it and test it with a smart phone, tracker hardware, etc.<br />
<br />
See also:<br />
* [https://electronics.stackexchange.com/a/156488 Reradiating antena for GPS]<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/index.php?title=User:Bertrik_Sikken&diff=31835User:Bertrik Sikken2023-11-18T13:42:45Z<p>Bertrik Sikken: /* XBEE */</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 (future)<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: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 />
=== 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 />
=== 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 />
https://nl.aliexpress.com/item/4000973201791.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 />
=== Blood pressure meter hacking ===<br />
Apparently some blood pressure monitors can be hacked.<br />
<br />
My goal is to be able to extract the list of the last 100 measurements somehow, so you don't have to type them over manually.<br />
Either using bluetooth (serial), or by adding something like an ESP8266 to sniff internally an make it available over WiFi.<br />
<br />
* bluetooth GATT profile for blood pressure monitors https://www.bluetooth.com/specifications/gatt/<br />
* hacking the UART on an Omron RS8 : https://blog.adafruit.com/2016/05/26/hacking-uart-to-an-omron-rs8-blood-pressure-sphygmomanometer/<br />
* https://hackaday.com/2015/10/11/push-blood-pressure-data-to-the-cloud-via-esp8266/<br />
* hacking a blood pressure monitor by monitoring i2c traffic to the EEPOM: https://www.edusteinhorst.com/hacking-a-blood-pressure-monitor/<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 />
=== GPS repeater ===<br />
This idea is about experimenting with a cheap GPS repeater built out of an "active" GPS antenna.<br />
<br />
The problem this solves is that often indoors you have no GPS reception, but you like to have some signal to experiment with (e.g. a LoRa tracker).<br />
<br />
Plan:<br />
* get a cheap active GPS antenna from AliExpress (some as cheap as E2,- !), most just mention one frequency (1575.42 MHz)<br />
* get a bias-T circuit to feed it the supply voltage (e.g. from a KOPPLA) and pass the RF signal onto an indoor antenna<br />
* the indoor antenna may be as simple as a 1/4 wave coax dipole: center conductor sticking up (about 47 mm), coax shielding is divided into 3 of 4 ground radials sticking sideways<br />
* build it and test it with a smart phone, tracker hardware, etc.<br />
<br />
See also:<br />
* [https://electronics.stackexchange.com/a/156488 Reradiating antena for GPS]<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/index.php?title=User:Bertrik_Sikken&diff=31834User:Bertrik Sikken2023-11-18T13:42:30Z<p>Bertrik Sikken: /* TinyGS */</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 (future)<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: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 />
=== 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 />
=== 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 />
=== XBEE ===<br />
I received a kind of XBEE zigbee router/repeater. Info<br />
* XBR-001-06<br />
* FCC ID: MCQ-PROS2B, see https://fccid.io/MCQ-PROS2B<br />
* IC: 1846A-PROS2B<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 />
https://nl.aliexpress.com/item/4000973201791.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 />
=== Blood pressure meter hacking ===<br />
Apparently some blood pressure monitors can be hacked.<br />
<br />
My goal is to be able to extract the list of the last 100 measurements somehow, so you don't have to type them over manually.<br />
Either using bluetooth (serial), or by adding something like an ESP8266 to sniff internally an make it available over WiFi.<br />
<br />
* bluetooth GATT profile for blood pressure monitors https://www.bluetooth.com/specifications/gatt/<br />
* hacking the UART on an Omron RS8 : https://blog.adafruit.com/2016/05/26/hacking-uart-to-an-omron-rs8-blood-pressure-sphygmomanometer/<br />
* https://hackaday.com/2015/10/11/push-blood-pressure-data-to-the-cloud-via-esp8266/<br />
* hacking a blood pressure monitor by monitoring i2c traffic to the EEPOM: https://www.edusteinhorst.com/hacking-a-blood-pressure-monitor/<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 />
=== GPS repeater ===<br />
This idea is about experimenting with a cheap GPS repeater built out of an "active" GPS antenna.<br />
<br />
The problem this solves is that often indoors you have no GPS reception, but you like to have some signal to experiment with (e.g. a LoRa tracker).<br />
<br />
Plan:<br />
* get a cheap active GPS antenna from AliExpress (some as cheap as E2,- !), most just mention one frequency (1575.42 MHz)<br />
* get a bias-T circuit to feed it the supply voltage (e.g. from a KOPPLA) and pass the RF signal onto an indoor antenna<br />
* the indoor antenna may be as simple as a 1/4 wave coax dipole: center conductor sticking up (about 47 mm), coax shielding is divided into 3 of 4 ground radials sticking sideways<br />
* build it and test it with a smart phone, tracker hardware, etc.<br />
<br />
See also:<br />
* [https://electronics.stackexchange.com/a/156488 Reradiating antena for GPS]<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/index.php?title=User:Bertrik_Sikken&diff=31833User:Bertrik Sikken2023-11-18T13:41:52Z<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<br />
* energy-related stuff, visualisation<br />
* citizen science, particulate matter measurement, noise (future)<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: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 />
=== 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 />
=== 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 />
=== TinyGS ===<br />
I run a tinyGS satellite ground station. It should be able to receive LoRa transmission from cube sats.<br />
<br />
Station page: https://tinygs.com/station/bertrik@1430247931<br />
<br />
Antenna design:<br />
* https://community.libre.space/t/an-easy-3d-printed-quadrifilar-helix-antenna/1487<br />
* https://gitlab.com/surligas/qfh-antenna/-/tree/master/433<br />
* meaning of the dimensions https://www.jcoppens.com/ant/qfh/calc.en.php<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 />
=== XBEE ===<br />
I received a kind of XBEE zigbee router/repeater. Info<br />
* XBR-001-06<br />
* FCC ID: MCQ-PROS2B, see https://fccid.io/MCQ-PROS2B<br />
* IC: 1846A-PROS2B<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 />
https://nl.aliexpress.com/item/4000973201791.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 />
=== Blood pressure meter hacking ===<br />
Apparently some blood pressure monitors can be hacked.<br />
<br />
My goal is to be able to extract the list of the last 100 measurements somehow, so you don't have to type them over manually.<br />
Either using bluetooth (serial), or by adding something like an ESP8266 to sniff internally an make it available over WiFi.<br />
<br />
* bluetooth GATT profile for blood pressure monitors https://www.bluetooth.com/specifications/gatt/<br />
* hacking the UART on an Omron RS8 : https://blog.adafruit.com/2016/05/26/hacking-uart-to-an-omron-rs8-blood-pressure-sphygmomanometer/<br />
* https://hackaday.com/2015/10/11/push-blood-pressure-data-to-the-cloud-via-esp8266/<br />
* hacking a blood pressure monitor by monitoring i2c traffic to the EEPOM: https://www.edusteinhorst.com/hacking-a-blood-pressure-monitor/<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 />
=== GPS repeater ===<br />
This idea is about experimenting with a cheap GPS repeater built out of an "active" GPS antenna.<br />
<br />
The problem this solves is that often indoors you have no GPS reception, but you like to have some signal to experiment with (e.g. a LoRa tracker).<br />
<br />
Plan:<br />
* get a cheap active GPS antenna from AliExpress (some as cheap as E2,- !), most just mention one frequency (1575.42 MHz)<br />
* get a bias-T circuit to feed it the supply voltage (e.g. from a KOPPLA) and pass the RF signal onto an indoor antenna<br />
* the indoor antenna may be as simple as a 1/4 wave coax dipole: center conductor sticking up (about 47 mm), coax shielding is divided into 3 of 4 ground radials sticking sideways<br />
* build it and test it with a smart phone, tracker hardware, etc.<br />
<br />
See also:<br />
* [https://electronics.stackexchange.com/a/156488 Reradiating antena for GPS]<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/index.php?title=PowerLight&diff=31832PowerLight2023-11-18T09:24:24Z<p>Bertrik Sikken: /* A model for the energy generation mix of the Netherlands */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== The model I use for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. Biomass + coal at CO2monitor is exactly equal to the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning a fixed fraction of the hard coal reported by ENTSO-E to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows (MWh/day) in/out the dutch natural gas system <br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=PowerLight&diff=31831PowerLight2023-11-18T09:23:52Z<p>Bertrik Sikken: /* Power generation data */</p>
<hr />
<div>{{Project<br />
|Name=PowerLight<br />
|Picture=PowerLight.jpg<br />
|Omschrijving=Shows mix of dutch electrical power generation as a pie chart on a LED ring<br />
|Status=Completed<br />
|Contact=bertrik<br />
}}<br />
<br />
== The concept ==<br />
Show the current dutch electrical power generation-mix as pie chart on a LED ring light, with colors representing fractions of a specific power generation source.<br />
<br />
For example:<br />
* yellow: solar<br />
* blue: wind<br />
* red: fossil<br />
* green: nuclear<br />
* purple: other/waste<br />
<br />
== Power generation data ==<br />
Information about energy in Europe is collected at the european organisation https://www.entsoe.eu/ .<br />
The section about electrical energy is collected in ENTSO-E.<br />
Data is available from this platform at a 15-minute interval.<br />
<br />
TenneT is the organisation that supplies ENTSO-E with data from the Netherlands.<br />
<br />
Information about ENTSO-E generation domain API:<br />
https://transparency.entsoe.eu/content/static_content/Static%20content/web%20api/Guide.html#_generation_domain<br />
<br />
Also possibly interesting (requires an API key), but might actually just use the entso-e data:<br />
https://static.electricitymap.org/api/docs/index.html#introduction<br />
<br />
==== ENTSO-E data ====<br />
ENTSO-E distinguishes energy generation into several types ("PsrType").<br />
This is how they are relevant to the data from the Netherlands:<br />
* B01 (biomass): always 0, not useful<br />
* B02: not available<br />
* B03: not available<br />
* <b>B04 (fossil hard coal): useful</b><br />
* <b>B05 (fossil gas): useful</b><br />
* B06: not available<br />
* B07: not available<br />
* B08: not available<br />
* B09 (geothermal): not available<br />
* B10 (hydro): not available<br />
* B11 (hydro): always 0<br />
* B12 (hydro): not available<br />
* B13 (marine): not available<br />
* <b>B14 (nuclear): useful</b><br />
* B15 (other renewable): not available<br />
* B16 (solar): hugely underreported, *not* useful<br />
* <b>B17 (waste): useful</b><br />
* <b>B18 (wind offshore): useful</b><br />
* <b>B19 (wind onshore): useful</b><br />
* <b>B20 (other): useful</b><br />
<br />
Additionally, ENTSO-E provides a day-ahead forecast for:<br />
* B16 (solar)<br />
* B18 (wind offshore)<br />
* B19 (wind onshore)<br />
<br />
==== A model for the energy generation mix of the Netherlands ====<br />
For me, the most insightful information came from this article by Bert Hubert:<br />
https://berthub.eu/articles/posts/dutch-electrical-power-figures-2/<br />
<br />
Main points relevant for me:<br />
* The solar part reported to entso-e is way too small. Note also at for example https://energy-charts.info/charts/energy_pie/chart.htm?l=en&c=NL that the solar part is tiny<br />
* On-shore wind data is unreliable, but off-shore wind data is probably OK<br />
* No biomass data is reported to entso-e<br />
<br />
There is a model that estimates the solar fraction, also at a regional level and at fine time resolution, at https://api.netanders.io/<br />
However use of this model requires a paid subscription, so I cant't use that.<br />
<br />
In my backend application, energy generation fractions are calculated as follows:<br />
* solar = B16 (from the time-shifted '''forecast''' document A69)<br />
* wind = B18 (offshore, from '''generation''' document A75) + B19 (onshore, from time-shifted '''forecast''' document A69) <br />
* fossil = B04 (gas) + B05 (coal)<br />
* nuclear = B14<br />
* waste = B17<br />
* other = B20<br />
<br />
Solar energy values from the forecast document show a systematic shift of about 30 minutes compared to other sources<br />
(e.g. sunrise/sunset data from national weather institute KNMI, energieopwek.nl)<br />
so forecast data from the ENTSO-E document is shifted by 30 minutes in my model.<br />
<br />
In the end, all of the electrical generation data used in my backend application is ENTSO-E data.<br />
<br />
==== Data model behind CO2monitor.nl ====<br />
Analysis:<br />
* Much of the data comes from ENTSO-E, except for at least solar, wind, biomass, WKK<br />
* Biomass data seems to follow the coal data exactly in shape. Biomass + coal at CO2monitor is exactly equal to the ENTSO-E hard coal number.<br />
* CO2monitor must be assigning a fixed fraction of the hard coal reported by ENTSO-E to biomass, it is unknown how they arrive at this fraction<br />
* The biomass fraction seems to be 1295/2740 = 47.3% (data from 18 november 2023)<br />
<br />
==== Data schedule ====<br />
Entso-E provides data with a resolution of 15 minutes.<br />
It appears to become available about 5m20s after the start of each 15 minute period (:00, :15, :30, :45).<br />
At that point, the most recent data is from an interval that ended 30 minutes ago.<br />
So, including the 5m20s minute processing delay, the most recent data available is about 35 minutes old.<br />
<br />
== Hardware ==<br />
<br />
Parts:<br />
* LED ring light, for example<br />
** 24-LED ring https://nl.aliexpress.com/item/32963152993.html I like this one, because it is in one piece and inexpensive<br />
** 40-LED ring https://nl.aliexpress.com/item/1005003798658173.html this has 4 segments that you have to join/solder<br />
** 60-LED ring https://nl.aliexpress.com/item/4000102576864.html also 4 segments<br />
* Wemos D1 mini board + pin headers, containing an ESP8266 microcontroller<br />
* "dupont"-cable, 4 wires<br />
* angled pin header, some rings have 2.0 mm pitch, others have 2.54 mm pitch<br />
* USB-A to USB-micro cable<br />
* 5V USB adapter<br />
<br />
Connecting it:<br />
* Solder the straight pin headers that came with it on the wemos d1 mini<br />
* Solder the angled pin to the LED ring<br />
* Connect the dupont cable:<br />
** Wemos 5V goes to 5V on the LED ring<br />
** Wemos GND goes to GND on the LED ring<br />
** Wemos D3 goes to DI on the LED ring<br />
** Wemos D2 goes to DO on the LED ring<br />
<br />
This [https://www.thingiverse.com/thing:3852495 picture stand] printed at 40% size works OK for the 24-LED ring.<br />
<br />
Diffuser: https://www.thingiverse.com/thing:751894 resize to 89x89x8 mm<br />
<br />
== Software ==<br />
The software consists of two parts:<br />
* The backend part that collects the power generation data, written in Java, running on a VPS<br />
* The light part that visualizes the power generation as fractions on a LED ring, running on an Arduino<br />
<br />
=== Backend ===<br />
Source code: https://github.com/bertrik/energymix-server<br />
<br />
Runs as a REST-like resource, with the following endpoints:<br />
* http://stofradar.nl:9001/electricity/generation with details about the current (35-50 minute ago) electricity generation mix, units are MW<br />
* http://stofradar.nl:9001/electricity/capacity with currently (per year) installed generation capacity, by source, units are MW<br />
* http://stofradar.nl:9001/electricity/price with day-ahead hourly electricity price-per-MWh for today, in euro/MWh, multiply by 0.001 to get euro/kWh<br />
* http://stofradar.nl:9001/naturalgas/price with daily natural gas prices (neutral gas price) of [https://en.wikipedia.org/wiki/Title_Transfer_Facility TTF] spot market, in euro/MWh, multiply by 35.17/3600 (= divide by 102.36 approximately) to get euro/m3<br />
* http://stofradar.nl:9001/naturalgas/flow with daily natural gas flows (MWh/day) in/out the dutch natural gas system <br />
<br />
Returns JSON-structures like:<br />
<pre><br />
{<br />
"time": 1657057500,<br />
"total": 9122,<br />
"mix": [<br />
{ "id": "solar", "power": 0, "color": "#FFFF00"},<br />
{ "id": "wind", "power": 4, "color": "#0000FF"},<br />
{ "id": "fossil", "power": 86, "color": "#FF0000"},<br />
{ "id": "nuclear", "power": 5, "color": "#FF00FF"},<br />
{ "id": "other", "power": 4, "color": "#444444"},<br />
{ "id": "waste", "power": 1, "color": "#444444"}<br />
]<br />
}<br />
</pre><br />
<br />
* time is a unix time stamp in seconds, representing the end of the 15-minute period that the power figures refer to<br />
* total is the total most recent electrical power (megawatt), suitable for display (on a numeric display inside the ring for example)<br />
* mix is an array of power sources, each with:<br />
** a short unique id<br />
** most recent known power (megawatt)<br />
** hex color, for display on the led ring<br />
<br />
<pre><br />
{<br />
"current": { "date": "2022-10-30","price": 32.02 },<br />
"day-ahead": [<br />
{ "date": "2022-10-31", "price": 62.631 },<br />
{ "date": "2022-11-01", "price": 49.293 }<br />
]<br />
}<br />
</pre><br />
<br />
=== Display ===<br />
==== LED ring energy mix ====<br />
[[File:electriciteitsmix.jpg|right|thumb]]<br />
<br />
Shows the dutch energy generation mix as a pie chart on a LED ring, one colour per source (solar/wind/fossil/etc)<br />
Source code: https://github.com/bertrik/PowerLight<br />
<br />
The Arduino sketch polls the REST API using HTTP every minute.<br />
<br />
The sketch auto-detects the number of LEDs in the ring, made possible by feeding the digital output of the last LED back into the microcontroller.<br />
<br />
WiFi is managed by WifiManager. LEDs are controlled using FastLED. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware that I used:<br />
* Wemos D1 mini, contains an ESP8266 + USB-serial converter<br />
* 24-led pixel ring, for example this one https://nl.aliexpress.com/item/32963152993.html<br />
* "dupont"-cable, you need 4 wires<br />
** wemos 5V to LED ring 5V<br />
** wemos GND to LED ring GND<br />
** wemos D3 to LED ring DI<br />
** wemos D2 to LED ring DO<br />
<br />
Firmware installation:<br />
* compiled using platformio<br />
* clone the code from github, enter the PowerLight directory<br />
* <pre>pio run -t upload</pre><br />
<br />
Configuration:<br />
* connect over WiFi to the "ESP-POWERLIGHT" network (no password)<br />
* open page at 192.168.4.1<br />
* enter WiFi credentials (select a network + password)<br />
<br />
==== LED ring price clock ====<br />
Idea: display relative electricity price on a clock face.<br />
* LED ring with 24 coloured leds, 2 leds per hour<br />
* colour indicates relative price, green = low, red = high<br />
* indicate current time by making the corresponding LED extra bright<br />
<br />
==== ElectricityPrice ====<br />
Shows the current dutch electricity price, based on the day-ahead prices from yesterday.<br />
Source code: https://github.com/bertrik/ElectricityPrice<br />
<br />
The Arduino sketch polls the REST price API using HTTP every 5 minutes.<br />
WiFi is managed by WifiManager. JSON content is parsed using ArduinoJSON.<br />
<br />
Hardware is an ESP8266 controlling a 7-segment display based on a TM1637, on pins D3 and D4.<br />
<br />
===== T-Display =====<br />
[[File:Nlecprice_mockup.png|right]]<br />
<br />
Alternative: use a TTGO ESP32 T-Display.<br />
<br />
It has a 240x135 pixel display.<br />
Plan is to show a kind of bar graph with 24 bars (one bar for each hour), each bar's height indicates the price of that hour.<br />
The background color shows green/black/red, to indicate cheap/moderate/expensive.<br />
Current price is shown as a big number.<br />
<br />
Each bar is therefore 10 pixels wide, 9 pixels for the bar + 1 pixel separation.<br />
<br />
===== SHA-badge =====<br />
The SHA2017 badge has an ESP32 capable of performing the HTTP request, processing the JSON and displaying the result on its display.<br />
These badges are limited-edition, a few thousand of them were made for the SHA-2017 event and they're no longer being produced.<br />
<br />
It has a 296x128 pixel epaper panel.<br />
So that could be a bar graph of 24 bars with a width of 12 pixels each, on the bottom 2/3rds of the display,<br />
and a current price on the top 1/3rd of the display. <br />
<br />
Could be run as a micropython sketch. Alternatively could be run as an Arduino sketch.<br />
<br />
Micropython:<br />
* ++ possibly quick development, script can be shared with other people<br />
* ++ has working libs for fetching HTTP, decoding JSON, controlling the display<br />
* -- script needs frequent garbage collection to avoid crashing?<br />
* -- unclear how to get a python script on this thing<br />
* -- sha badge firmware bootloops, currently unusable to me<br />
<br />
Arduino:<br />
* ++ I know this environment, don't have to debug existing bootlooping firmware, no compiler setup required<br />
* ++ Already have HTTP and JSON working on Arduino<br />
* ++ Code starts immediately, no user interaction required<br />
* -- not sure if there is a usable epaper driver</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Eten_bestellen&diff=31819Eten bestellen2023-11-09T12:06:59Z<p>Bertrik Sikken: make sortable</p>
<hr />
<div>Wil jij nomz bestellen? Hieronder staat een lijst met meningen en restaraunts.<br />
<br />
= Restaurants =<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Naam !! Categorie !! Vegetarisch !! Vegan !! Rating !! Kosten !! Snel !! Extra<br />
|-<br />
| [https://www.thuisbezorgd.nl/menu/haringpaleis Haringpaleis ] || Fish || Ja || ? || 4/5 || Oke || Ja || Prima kibbeling, let er op dat je kabeljauw kibbeling kiest anders krijg je koolvis<br />
|-<br />
| [https://the-butcher.com/thehague/ The Butcher] || Hamburgers || ? || ? || 4/5 || Duur || Ja || Prima kwaliteit burgers<br />
|-<br />
| [https://shanasheelbbq.nl/nl/ Shanasheel] || Iraakse BBQ || ? || ? || 4/5 || Duur || Ja || Heerlijke houtskool spareribs, de portie is klein<br />
|-<br />
| [https://www.fayaplaza-voorburg.nl/ Rotishop Faya Plaza] || Roti || Ja || Ja || 4/5 || Duur || Ja || Roti is lekker, de rest niet.<br />
Note from Folkert: Volgens Zawadi was de bara te dik, maar was prima. Zawadi: Een bara hoort geen oliebol te zijn.<br />
|-<br />
| [https://www.jeffrey-grill.nl/ Jeffrey Grill] || Grill (Spareribs) || Nee || Nee || 3.5/5 || Ok || Ja || De spareribs zijn lekker maar wel erg taai!<br />
|-<br />
| [https://www.grillrestaurant-telaviv.nl/ Tel Aviv] || Grill (Spareribs) || Nee || Nee || 3.5/5 || Ok || Ja || Prima spareribs voor een afhaaltoko<br />
|-<br />
| [https://www.eflatundoner.nl/ Eflatun] || Turks || Ja || Nee || 3.5/5 || Ok || Ja || Lekker Turks eten wel veel vet en altijd op tijd. (vegetarisch mogelijk)<br />
|-<br />
| [https://www.jjskitchen.nl/ JJ's Kitchen] || Surinaams || Ja || Nee || 2.5/5 || Duur || Nee || Oke de kwaliteit is steeds minder<br />
|-<br />
| [https://fratellikerkstraat.foodticket.nl/foodticket/cgi/bestel.cgi Fratelli] || Pizza || Ja || Ja|| 4/5 || Ja || Meestal || Pizza.<br />
|-<br />
| [https://www.pizzaportobello.nl/ Porto Bello] || Pizza || Ja || Ja-ish (zonder kaas) || 3/5 || Ja || Meestal || Pizza.<br />
|-<br />
| [https://www.pizzapronto-leidschendam.nl/ Pizza Pronto] || Pizza || Ja || Nee || 3/5 || Ja || Soms || Wederom Pizza.<br />
|-<br />
| [https://www.royalcurry.nl/ Royal Curry] || Indiaas || Ja || Nee? || 4.5/5 || Ok || Nee || De default Indiaas voor de vrijdagavond.<br />
Note from Noor: Worst Indian food I've had, very bland, and I'm not a picky eater who has had plenty of *good* Indian food all over three continents.<br />
<br />
Note from pinoaffe: Really good indian food, I think Noor is alone on this one<br />
|-<br />
| [https://leidschendam.pannenkoe.nl/ Pannenkoe] || Pannenkoeken (ook hartig) || Ja || Ja || 4/5 || Duur || Dunno || Hip restaurant iets duur, pannenkoeken en andere dingen.<br />
|-<br />
| [https://leidschendam.foodmaster.nl/?radius=10 Foodmaster Sytwinde ] || Snackbar || Ja || Nee || 3/5 || Meh || Meestal || Goeie snackbar.<br />
|-<br />
| [https://www.snackbar-het-pleintje.nl/ Snackbar 't Pleintje ] || Snackbar || Ja || Nee || 4/5 || Ok || Meestal || Betere snackbar.<br>''Weet je 't zeker? We hadden erg dure erg karige turkse pizza's.''<br />
|-<br />
| [https://dapur-ibu.nl/ Dapur Ibu Toko] || Indo || Ja || Nee? || 4/5 || Prima || || Prima indonesche rijsttafel<br />
|-<br />
| [https://www.pavarotti.nl/karaoke/ Pavarotti] || Pizza || Ja? || Nee? || 1/5 || Prima || || Hier kreeg een deelnemer voedsel vergiftiging van.<br />
|-<br />
| [https://www.thuisbezorgd.nl/menu/midnight-roti-vuursteen Midnight Roti Shop Ypenburg] || Roti || Ja || Ja || 4.5/5 || Prima || Ja || Binnenkort alleen bestellen via [https://vuursteen.rotibode.nl/ eigen site]<br />
|-<br />
| [https://www.deedees-denhaag.nl/ Dee Dee's] || Turks || Ja || Nee? || 2/5 || Meh || ¾uur || Kip in de kapsalon niet de moeite waard, patat was wel goed. Turkse pizza niet volgens de custom ingrediënten lijst (saus verkeerd)<br />
|}<br />
<br />
'''Niet doen'''<br />
* Jimmy/Johny Burger - Een slappe burger voor een hoge prijs</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31804NoiseMeter2023-11-03T15:53:10Z<p>Bertrik Sikken: /* Casing */</p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects:<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek, ESP32 with I2S microphone, shares many concepts with [[EspAudioSensor]]<br />
* [https://github.com/bertrik/LoraWanPmSoundSensor LoRaWAN PM/Sound sensor] by Bas van Drunen, shares many concepts with [[LoraWanDustSensor]]<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project page considers a kind of clone of the Amsterdam Sounds project.<br />
<br />
== Hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on Arduino, a kind of clone of the Amsterdam Sounds project, modified to use WiFi (instead of LoRa), written by Rene Kuijf.<br />
<br />
My modifications consist of a platformio configuration, for easy building.<br />
<br />
See [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 AdamSoundsInflux-slim-nano-33 github repo] for the source code.<br />
<br />
== Casing ==<br />
<br />
=== Microphone protection ===<br />
To protect the microphone, use a membrane, like:<br />
* https://nl.aliexpress.com/item/1005002288893298.html "AOCARMO"<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm<br />
<br />
[[Category:Arduino]]<br />
[[Category:Arduino Nano 33 IoT]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31803NoiseMeter2023-11-03T15:10:52Z<p>Bertrik Sikken: /* Casing */</p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects:<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek, ESP32 with I2S microphone, shares many concepts with [[EspAudioSensor]]<br />
* [https://github.com/bertrik/LoraWanPmSoundSensor LoRaWAN PM/Sound sensor] by Bas van Drunen, shares many concepts with [[LoraWanDustSensor]]<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project page considers a kind of clone of the Amsterdam Sounds project.<br />
<br />
== Hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on Arduino, a kind of clone of the Amsterdam Sounds project, modified to use WiFi (instead of LoRa), written by Rene Kuijf.<br />
<br />
My modifications consist of a platformio configuration, for easy building.<br />
<br />
See [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 AdamSoundsInflux-slim-nano-33 github repo] for the source code.<br />
<br />
== Casing ==<br />
To protect the microphone, use a membrane, like:<br />
* https://nl.aliexpress.com/item/1005002288893298.html<br />
<br />
I'm looking into several options:<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm<br />
<br />
[[Category:Arduino]]<br />
[[Category:Arduino Nano 33 IoT]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31802NoiseMeter2023-11-02T15:32:54Z<p>Bertrik Sikken: /* Software */</p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects:<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek, ESP32 with I2S microphone, shares many concepts with [[EspAudioSensor]]<br />
* [https://github.com/bertrik/LoraWanPmSoundSensor LoRaWAN PM/Sound sensor] by Bas van Drunen, shares many concepts with [[LoraWanDustSensor]]<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project page considers a kind of clone of the Amsterdam Sounds project.<br />
<br />
== Hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on Arduino, a kind of clone of the Amsterdam Sounds project, modified to use WiFi (instead of LoRa), written by Rene Kuijf.<br />
<br />
My modifications consist of a platformio configuration, for easy building.<br />
<br />
See [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 AdamSoundsInflux-slim-nano-33 github repo] for the source code.<br />
<br />
== Casing ==<br />
I'm looking into several options:<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm<br />
<br />
[[Category:Arduino]]<br />
[[Category:Arduino Nano 33 IoT]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31801NoiseMeter2023-11-02T15:31:30Z<p>Bertrik Sikken: /* Software */</p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects:<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek, ESP32 with I2S microphone, shares many concepts with [[EspAudioSensor]]<br />
* [https://github.com/bertrik/LoraWanPmSoundSensor LoRaWAN PM/Sound sensor] by Bas van Drunen, shares many concepts with [[LoraWanDustSensor]]<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project page considers a kind of clone of the Amsterdam Sounds project.<br />
<br />
== Hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on Arduino, written by Rene Kuijf.<br />
It is built using platformio<br />
<br />
* [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 software repo]<br />
<br />
== Casing ==<br />
I'm looking into several options:<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm<br />
<br />
[[Category:Arduino]]<br />
[[Category:Arduino Nano 33 IoT]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31800NoiseMeter2023-11-02T15:30:24Z<p>Bertrik Sikken: /* hardware */</p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects:<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek, ESP32 with I2S microphone, shares many concepts with [[EspAudioSensor]]<br />
* [https://github.com/bertrik/LoraWanPmSoundSensor LoRaWAN PM/Sound sensor] by Bas van Drunen, shares many concepts with [[LoraWanDustSensor]]<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project page considers a kind of clone of the Amsterdam Sounds project.<br />
<br />
== Hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on arduino, built using platformio.<br />
<br />
* [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 software repo]<br />
<br />
== Casing ==<br />
I'm looking into several options:<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm<br />
<br />
[[Category:Arduino]]<br />
[[Category:Arduino Nano 33 IoT]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31799NoiseMeter2023-11-02T15:30:10Z<p>Bertrik Sikken: /* Introduction */</p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects:<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek, ESP32 with I2S microphone, shares many concepts with [[EspAudioSensor]]<br />
* [https://github.com/bertrik/LoraWanPmSoundSensor LoRaWAN PM/Sound sensor] by Bas van Drunen, shares many concepts with [[LoraWanDustSensor]]<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project page considers a kind of clone of the Amsterdam Sounds project.<br />
<br />
== hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on arduino, built using platformio.<br />
<br />
* [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 software repo]<br />
<br />
== Casing ==<br />
I'm looking into several options:<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm<br />
<br />
[[Category:Arduino]]<br />
[[Category:Arduino Nano 33 IoT]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31798NoiseMeter2023-11-02T15:29:11Z<p>Bertrik Sikken: /* Introduction */</p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects:<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek, ESP32 with I2S microphone, shares many concepts with [EspAudioSensor]<br />
* [https://github.com/bertrik/LoraWanPmSoundSensor LoRaWAN PM/Sound sensor] by Bas van Drunen, shares many concepts with [LoraWanDustSensor]<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project is about a kind of clone of the Amsterdam Sounds project.<br />
<br />
== hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on arduino, built using platformio.<br />
<br />
* [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 software repo]<br />
<br />
== Casing ==<br />
I'm looking into several options:<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm<br />
<br />
[[Category:Arduino]]<br />
[[Category:Arduino Nano 33 IoT]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31781FMCWRadar2023-10-27T18:04:37Z<p>Bertrik Sikken: /* RD-03 */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:aithinker-rd03-1.png|thumb|right|aithinker rd-03]]<br />
[[File:aithinker-rd03-2.png|thumb|right|aithinker rd-03]]<br />
<br />
Parts:<br />
* radar chip: S3KM1110<br />
* controller chip: F003F17 / 2L6T13B, PY32F003F17U<br />
<br />
This thing outputs ASCII strings over a serial port at 115200, for example:<br />
<pre><br />
ON<br />
Range 46<br />
</pre><br />
<br />
That appears to be all.<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31780FMCWRadar2023-10-27T17:34:35Z<p>Bertrik Sikken: /* RD-03 */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:aithinker-rd03-1.png|thumb|right|aithinker rd-03]]<br />
[[File:aithinker-rd03-2.png|thumb|right|aithinker rd-03]]<br />
<br />
Parts:<br />
* radar chip: S3KM1110<br />
* controller chip: F003F17 / 2L6T13B, PY32F003F17U<br />
<br />
This thing outputs ASCII strings over a serial port at 115200, for example:<br />
<pre><br />
ON<br />
Range 46<br />
</pre><br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31779FMCWRadar2023-10-27T16:32:17Z<p>Bertrik Sikken: /* RD-03 */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:aithinker-rd03-1.png|thumb|right|aithinker rd-03]]<br />
[[File:aithinker-rd03-2.png|thumb|right|aithinker rd-03]]<br />
<br />
Parts:<br />
* radar chip: S3KM1110<br />
* controller chip: F003F17 / 2L6T13B, PY32F003F17U<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=File:Aithinker-rd03-2.png&diff=31778File:Aithinker-rd03-2.png2023-10-27T15:59:56Z<p>Bertrik Sikken: </p>
<hr />
<div></div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31777FMCWRadar2023-10-27T15:56:56Z<p>Bertrik Sikken: /* RD-03 */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:aithinker-rd03-1.png|thumb|right|aithinker rd-03]]<br />
[[File:aithinker-rd03-2.png|thumb|right|aithinker rd-03]]<br />
<br />
Parts:<br />
* radar chip: S3KM1110<br />
* controller chip: F003F17 / 2L6T13B<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=File:Aithinker-rd03-1.png&diff=31776File:Aithinker-rd03-1.png2023-10-27T15:54:21Z<p>Bertrik Sikken: </p>
<hr />
<div></div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31775FMCWRadar2023-10-27T15:54:07Z<p>Bertrik Sikken: /* RD-03 */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:aithinker-rd03-1.png|thumb|right|aithinker rd-03]]<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31774FMCWRadar2023-10-27T15:45:37Z<p>Bertrik Sikken: /* RD-03 */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
[[File:ai-rd-03a.png|thumb|right|aithinker rd-03]]<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31773FMCWRadar2023-10-27T13:55:48Z<p>Bertrik Sikken: /* Available FMCW radar modules */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Ai Thinker ==<br />
=== RD-03 ===<br />
<br />
<br />
== Various ==<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=FMCWRadar&diff=31772FMCWRadar2023-10-27T13:55:13Z<p>Bertrik Sikken: /* Various */</p>
<hr />
<div>{{Project<br />
|Name=FMCWRadar<br />
|Picture=hlk-ld303-24g.jpg<br />
|Omschrijving=Experimenting with inexpensive FMCW radar modules<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
= What =<br />
This project is about experimenting with inexpensive FM-CW radar modules as can be found on AliExpress:<br />
* gaining experience with the hardware<br />
* gaining experience on what kind of compensation/calibration is needed<br />
* apply it in a fun project, e.g. pedestrian speed indicator, or detect bats with it<br />
<br />
Perhaps start a collection of inexpensive "software-defined" radar projects?<br />
<br />
The current generation of inexpensive radar modules (around E40,-) has these typical features:<br />
* operates on 24 GHz<br />
* has quadrature outputs (I and Q) so it can not just detect movement (through Doppler) but also distinguish direction<br />
* has a modulation input that allows a subtle change of the radar operating frequency<br />
* often combined with a cortex M0 or M3/M4 microcontroller, <br />
* pre-configured with firmware to do detection of object speed and direction<br />
<br />
External links:<br />
* [https://ik1zyw.blogspot.com/search/label/24%20GHz Experiments making 24 GHz radio links using inexpensive radar modules] by IK1ZYW<br />
* [https://www.limpkin.fr/index.php?post/2017/02/22/Making-the-Electronics-for-a-24GHz-Doppler-Motion-Sensor Interesting investigation into the electronics] for the (relatively simple, no IQ, no FMCW) CDM324 24 GHz sensor.<br />
* Interesting article about an investigation into doppler sensors like this http://ael.chungbuk.ac.kr/lectures/graduate/ICT%EC%9C%B5%ED%95%A9%ED%8A%B9%EB%A1%A0/13/13-no-voice.pdf<br />
<br />
= Theory =<br />
An FM-CW radar is a few steps more advanced than the very basic Doppler radars (like the HB-100), typically:<br />
* I and Q outputs as described above<br />
* Modulation input, that allows you to quickly sweep the radar frequency<br />
<br />
The basic idea behind an FM-CW radar is that the frequency is sweeped, at some continuous rate.<br />
A signal that is reflected by an object in the view of the radar, will arrive back at the radar with some delay.<br />
Because of the delay, the outgoing signal will have already changed in frequency compared to the incoming reflected frequency.<br />
At the radar, the delayed reflected signal is "mixed" with the outgoing signal, resulting in a low-frequency I+Q output of the difference frequency.<br />
The difference frequency at the output of the radar is therefore linearly related to the time delay, so also linearly related to the object distance.<br />
<br />
=== IVS-362 ===<br />
The [https://www.innosent.de/fileadmin/media/dokumente/datasheets/190529_User_Manual_IVS-362.pdf IVS-362] from Innosent is a tunable 24 GHz radar module, with the following typical specifications<br />
* tuning voltage range about 0.7 - 2.5 V = 1.8V<br />
* modulation sensitivity = 720 MHz/V <br />
<br />
=== NJR ===<br />
https://www.njr.com/micro/download/datasheet/sensor/NJR4234BV_Datasheet_Rev00-02e.pdf<br />
<br />
* mentions a sweep time of 1024 us, supporting the typical 1 ms sweep time assumed in the calculation below<br />
* mentions a bandwidth of 177 MHz, comparable with the assumption as used in the calculation below<br />
<br />
=== calculation ===<br />
I have very little to go on, so making a couple of assumptions:<br />
* radar works at 24 GHz, therefore wavelength = 12.5 mm<br />
* suppose the range of a full FM sweep is '''150 MHz'''<br />
* object distance d is '''1 meter''', so time-of-flight = 2 * d / c = 6.67 ns<br />
* to get a '''1 kHz''' difference frequency at this range, we need a chirp rate of delta_f / delta_t = 1 kHz / 6.67 ns = 150 GHz/s<br />
* the FM sweep therefore has to be done in 150 MHz / 150 GHz/s = '''1 ms''', or 1000 sweeps/s<br />
* suppose the FM sweep consists of 100 individual steps, we need 100,000 steps/s<br />
<br />
So the modulation output needs to be updated at 100 kHz, and the IQ inputs needs to be sampled at (say) 10 kHz.<br />
Quite challenging, but not necessarily impossible.<br />
<br />
= Challenges =<br />
* Hardware:<br />
** do the available radar modules actually use the FM modulation input of the radar? -> I will assume that unless it's specifically advertised, this is NOT the case (even though it uses a frontend that could)<br />
** how is the FM modulation input wired to the CPU? The STM32 processors typically used don't have a DAC output! -> is the ramp perhaps generated with help of an opamp circuit (e.g. current source charging a capacitor)<br />
** some STM32 MCUs *do* have a DAC, see [https://www.st.com/resource/en/application_note/cd00259245-audio-and-waveform-generation-using-the-dac-in-stm32-microcontrollers-stmicroelectronics.pdf this application note]<br />
* Software:<br />
** can we find source code of existing firmwares? -> probably NO at this point<br />
** can we reprogram the microcontroller -> SWD-signals are generally brought out to a header -> might be flash locked, might be possible to physically replace with an unlocked STM32<br />
*** [https://www.st.com/resource/en/application_note/dm00186528-proprietary-code-readout-protection-on-microcontrollers-of-the-stm32f4-series-stmicroelectronics.pdf This application note] describes the levels: in short 0 = fully unlocked, 1 = flash locked but JTAG/SWD/etc still works, unlock erases flash, 2 = fully locked, JTAG/SWD/etc disabled<br />
* How to cope with real-world inaccuracies, like IQ inbalance -> I guess now that a linear correction matrix can fix most of it, but how to determine the coefficients, preferably automatically <br />
** I-Q outputs are not exactly 90 degrees apart<br />
** I-Q outputs have an amplitude inbalance<br />
** I-Q outputs have a bias<br />
** dynamic range: this needs to be high, since the radar equation has a 4th-power dependency on distance -> maybe not so critical, range detection relies on measuring a frequency, not an amplitude<br />
* Get some rough idea of<br />
** inaccuracies a described above<br />
** Frequency change per m/s<br />
** Typical modulation index: MHz / V on the modulation input, and the corresponding sweep rate > 150 MHz / ms doesn't seem unreasonable<br />
* Choose signal processing properties<br />
** choose an appropriate sample rate<br />
** can we calculate an FFT fast enough, fixed point or floating point<br />
** what properties should the FFT have, obviously complex->complex, window function?<br />
** can we stack multiple FFTs for increased sensitivity? -> yes probably, stack them in IQ (not power)<br />
<br />
= Available FMCW radar modules =<br />
<br />
== Various ==<br />
Ai Thinker:<br />
* RD-03:<br />
<br />
DF robot:<br />
* https://wiki.dfrobot.com/mmWave_Radar_Human_Presence_Detection_SKU_SEN0395<br />
<br />
Acconeer radars:<br />
* https://www.acconeer.com/products has a list of smart radar modules<br />
* https://learn.sparkfun.com/tutorials/getting-started-with-the-a111-pulsed-radar-sensor/all<br />
<br />
From Yanwu Tech:<br />
* [https://rfbros.com/product-category/fmk24-a-series/ FMK24-A series], a range of FMCW modules which appear identical in hardware at least, a.k.a. as "FM24-NP100".<br />
* [https://www.aliexpress.com/item/32880286864.html FM24-NP100] on Aliexpress.<br />
<br />
AliExpress 24 GHz radar with FMCW, no CPU:<br />
* [https://nl.aliexpress.com/item/4000019605145.html Yh-24g04, a 24 GHz quadrature doppler radar] (no CPU), has modulation input, for about E16,-<br />
* [https://nl.aliexpress.com/item/4000012550318.html YH-24G01] (no CPU), for about E15,-<br />
<br />
AliExpress 24 GHz radar with FMCW, with CPU:<br />
* [https://nl.aliexpress.com/item/4001178723480.html IMD2411A2] (has some 32 pin IC)<br />
* [https://nl.aliexpress.com/item/4001178786384.html IFL2411A2]<br />
-> claimed to support FMCW, outputs for divided signal, temperature, for about E15,- . See also https://img.alicdn.com/imgextra/i1/2207378167020/O1CN01dUjv6p21jD06t4F3w_!!2207378167020.jpg . Appears to suggest that the IMD2411A2 uses 3.0V and the IFL2411A2 uses 3.3V. Both have "ADC DAC" interface.<br />
* [https://nl.aliexpress.com/item/4001178777287.html RD2411A] has a review claiming it actually works for distance measurement up to 5m: "The seller sended a datasheet of the unit, so I was able to read out the unit. measurements till 5 meters are no problem, I did not test greater distances. The measurement speed is very low, and needs 600ms. The current stays at 150mA, so it is not very usable in battety equipment "<br />
<br />
This series appears to use the Infineon radar chip <br />
BGT24LTR11<br />
see also their [https://www.infineon.com/dgdl/Infineon-AN472_BGT24LTR11N16_users_guide-ApplicationNotes-v01_04-EN.pdf application note 472].<br />
<br />
AliExpress 24 GHz radar, DM-series:<br />
* [https://nl.aliexpress.com/item/33063598872.html DM-39, a 24 GHz quadrature doppler radar] with CPU for about E32,-. The page shows a SRK1101 radar, with I/Q outputs and tune input. Mentions Cortex M0.<br />
* [https://nl.aliexpress.com/item/4000199485196.html DM-19, a 24 GHz quadrature doppler radar] with CPU for about E48,-. Appears similar in possibilities to DM-39. Mentions Cortex M3/M4 processor.<br />
* [https://nl.aliexpress.com/item/33063634093.html another DM-19, 24 GHz quadrature doppler radar], about E40,-<br />
* [https://nl.aliexpress.com/item/4000021962721.html DM-19 / DB-16] another FMCW radar model, about E39,-<br />
Even though the front-end used can be modulated, no mention is made of FMCW or ranging application!<br />
<br />
AliExpress 24 GHz radar, FM-series:<br />
* [https://nl.aliexpress.com/item/4000189129731.html FM-42, a 24 GHz FMCW radar] with CPU for about USD107,-<br />
* [https://www.aliexpress.com/i/4000069654418.html FM-49] another FMCW radar module, M3/M4 CPU, claims range 4m, accuracy 5 cm, about E52,-<br />
<br />
AliExpress 24 GHz radar, other:<br />
* [https://nl.aliexpress.com/item/4000727301659.html 182MOD, a module outputting speed] for about USD28,- appears to use a 5-pin radar (Vcc,Gnd,I,Q,tune?)<br />
* [https://nl.aliexpress.com/item/4000385426235.html USRR187] mentions FMCW, has CPU (UART output), pin defintion not clear, for about E38,-<br />
* [https://www.aliexpress.com/item/4000727277957.html TD-24G-B-002], claims to support ranging, but information is confusing, about E21,- More information: http://www.hrtsensor.com/prodetail-13346865.html<br />
<br />
== Hi-link ==<br />
Hi-link radars, available on AliExpress, typically separate analog frontend + CPU for processing, serial output:<br />
* [https://nl.aliexpress.com/item/1005004786874722.html HLK-LD2410] 24G Fmcw 24Ghz, controller chip with markings "S3KM111L" / "15J0101D1". Interesting project on github: https://github.com/ncmreynolds/ld2410<br />
* [https://nl.aliexpress.com/item/1005004255401209.html HLK-LD015-5G] 5.8G Radar Sensor Module, has a controller chip with markings "5810S" / "20380A"<br />
* [https://nl.aliexpress.com/item/1005004143553436.html HLK-LD1115H-24G] claims static detection up to 5 m, dynamic detection up to 16m<br />
* [https://nl.aliexpress.com/item/1005004255546033.html HLK-LD112 24GHz] simple motion detector, radar chip with markings "111A" / "2010" + BISS0001 motion detector chip<br />
* HLK-LD303-24G see [https://revspace.nl/FMCWRadar#HLK-LD303-24G below]<br />
<br />
== Analog front-end ==<br />
Analog front-end for many of the radar modules above seems to be [http://www.sgrsemi.com/content/?22.html SRK1101A]:<br />
* [http://www.tekscopeau.com/?page_id=212 this page] claims it has an SPI interface, but I doubt that<br />
* 250 MHz bandwidth<br />
* 25 dB receive gain<br />
* run at 3.3V, 58 mA current typical<br />
* 16 pins<br />
<br />
= Experimentation =<br />
<br />
== HLK-LD2410 ==<br />
Expimental software to communicate with this module, running on ESP8266:<br />
https://github.com/bertrik/hlk-ld2410<br />
<br />
Information: https://drive.google.com/drive/folders/1p4dhbEJA3YubyIjIIC7wwVsSo8x29Fq-<br />
<br />
Hardware:<br />
* radar-side: S3KM111L / 1540101D1 / 2209H<br />
* electronics side: BPCK234-23A2<br />
<br />
Protocol: https://github.com/ESPresense/ESPresense/files/9312938/HLK-LD2410.Serial.Communication.Protocol.V1.02.pdf<br />
<br />
Apparently, the device has two kinds of responses:<br />
* ACK, in response to a command, starting with bytes FD FC FB FA<br />
* measurement report, sent unsollicited, starting with bytes F4 F3 F2 F1<br />
<br />
Next steps:<br />
* add function to configure the module for a more reasonable bit rate (e.g. 9600 bps) instead of 256000 bps<br />
<br />
== HLK-LD1115H-24G ==<br />
Information at manufacturer: https://hlktech.net/index.php?id=973&cateid=749<br />
<br />
Can't find a proper datasheet, but found some info here:<br />
https://community.home-assistant.io/t/how-to-work-with-hlk-ld1115h-and-wemos-d1-mini-for-human-presence-detection/434427<br />
<br />
It mainly outputs two messages:<br />
* occ, for occupancy (or small movement)<br />
* mov, for movement (or large movement)<br />
<br />
=== Hardware ===<br />
* radar front-end, chip says: SGR / 1101 / 2147, probably SGR semi chip SRK1101, manufactured in 2021 week 47.<br />
* microcontroller: ST (e4) GK05B / 32F030F4P6 / CHN145RNA, probably equivalent to STM32F030F4 https://www.st.com/en/microcontrollers-microprocessors/stm32f030f4.html <br />
* 5-pin power regulator (?): LN30, possibly 3.0V voltage regulator<br />
* 8-pin opamp: RS622, M906130, datasheet https://datasheet.lcsc.com/lcsc/2010160506_Jiangsu-RUNIC-Tech-RS622XTDE8_C255452.pdf<br />
* there are 4 pads supposedly for flashing/debugging: SCK, SDO, GND, VCU<br />
* 3 unused/empty footprints for a 3-pin component<br />
<br />
=== Software ===<br />
<br />
== YH-K24-G01 ==<br />
I have an YH-K24-G01.<br />
<br />
It works as a Doppler sensor.<br />
<br />
I could not get the modulation input to have any effect on the detection. Tried it with a couple volts at 1 kHz, 10 kHz, 100 kHz.<br />
No effect. A review at AliExpress complains about the modulation input having no effect. Maybe I accidentally destroyed it (have been careful though).<br />
I measure about 150 ohm from the tune-input to both ground and Vcc, so at least the tune input is not completely isolated.<br />
<br />
== HLK-LD303-24G ==<br />
[[File:hlk-ld303-24g.jpg|thumb|right|HLK-LD303-24G]]<br />
<br />
Ordered an HLK-LD303-24G module, on [https://nl.aliexpress.com/item/1005001994780065.html AliExpress].<br />
Inexpensive, combines a 24 GHz radar module with a microcontroller (STM32 or compatible).<br />
<br />
More info: https://www.hlktech.com/en/Goods-94.html<br />
<br />
=== Hardware ===<br />
Components on this board:<br />
* An "CKCA32" STM32-compatible in LQFP-48 pinout<br />
* MV324, quad opamp<br />
* 8 MHz crystal<br />
* HT50 (5V regulator?) plus two 3.3V regulators (probably)<br />
* radar is an Infineon BGT24LTR11N16 (package says "LTR11" "2020")<br />
<br />
The PCB has two pads, marked I and Q near the opamp. So probably at least two of the opamps in the quad-opamp are dedicated to amplification/buffering of the I and Q signals.<br />
Signal I goes to pin PA2/ADC12_IN2.<br />
Signal Q goes to pin PA3/ADC12_IN3.<br />
Perhaps there are two opamps for generation of the FMCW modulation signal?<br />
<br />
Oddly enough, I cannot find a signal going from the I and Q signals to the opamp, so perhaps the opamp has nothing to do with the I and Q signals at all!<br />
Possibly only used for generation an FMCW ramp?<br />
<br />
There is a blue LED connected to pin PB9.<br />
<br />
STM32 pinout<br />
{| class="wikitable"<br />
! Pin<br />
! Name<br />
! Function<br />
|-<br />
| 12 || PA2/ADC12_IN2 || radar-I<br />
|-<br />
| 13 || PA3/ADC12_IN3 || radar-Q<br />
|-<br />
| 26 || PB13/SPI2_SCK || ???<br />
|-<br />
| 30 || PA9/USART1_TX || serial TX?<br />
|-<br />
| 31 || PA10/USART1_RX || serial RX?<br />
|-<br />
| 46 || PB9 || blue LED<br />
|}<br />
<br />
=== Pinout ===<br />
{| class="wikitable"<br />
! Arduino<br />
! Module<br />
! Remark<br />
|-<br />
| D2 || red wire || Arduino TX<br />
|-<br />
| D3 || yellow wire || Arduino RX<br />
|-<br />
| GND || black wire || ground<br />
|-<br />
| 5V || white wire || power<br />
|}<br />
<br />
NOTE: the pinout as shown on the PCB *does not* match the header!<br />
<br />
=== Parameters ===<br />
Internal parameters of the HLK-LD303, partially inferred from datasheets (translated from Chinese):<br />
<br />
{| class="wikitable"<br />
!Code!!Parameter!!Parameter value!!Remarks<br />
|-<br />
| B1 || Operating mode || 0 = sensitive, 1 = stable || -<br />
|-<br />
| B3 || Fitting coefficient (0.001) || ? || -<br />
|-<br />
| B4 || Offset correction (cm) || ? || -<br />
|-<br />
| D1 || Delay time (ms) || 200-3000, default 1000 || The time the output (blue LED) stays active after detection<br />
|-<br />
| D2 || Close treatment || 0 = keep last measured distance, 1 = clear distance result || -<br />
|-<br />
| D3 || Measurement || - || Start measurement in mode 6, using the 'query' command packet<br />
|-<br />
| D4 || Baud rate (unit 100 bps) || - || Set baud rate, activated on next power-up<br />
|-<br />
| D5 || Trigger threshold (unit: 'k') || 30-3000, default 100 || -<br />
|-<br />
| D9 || Output target || 0 = nearest, 1 = maximum goal || ?<br />
|-<br />
| DA || Signal interval (unit: 40ms) || 5-20, default 10 || <br />
|-<br />
| DE || Reset || 0 || <br />
|-<br />
| E0 || Minimum detection distance (cm) || 0-200, default 30 || -<br />
|-<br />
| E1 || Sensitivity || 60-2000, default 300 || Smaller number means more sensitive, it acts like an activity threshold for detection<br />
|-<br />
| E5 || Maximum detection distance (cm) || 50-350, default 350 || -<br />
|-<br />
| E6 || Report interval (unit: 40ms) || 0-20 || -<br />
|-<br />
| E7 || Extreme values stats || 0-100, default 0 || -<br />
|-<br />
| E8 || Extreme filter times || default 0 || -<br />
|-<br />
| E9 || Number of swipes || 0-100, default 10 || -<br />
|-<br />
| F6 || Protocol type || 0=ASCII,1=?,6=query,7=automatic || -<br />
|-<br />
| F9 || Proportion statistic || 0-100, default 20 || -<br />
|-<br />
| FA || Invalid distance (cm) || 10-1000, default 30 || -<br />
|-<br />
| FB || Percentage (%) || 10-100, default 30 || -<br />
|-<br />
| DF || Firmware upgrade || 1 || -<br />
|-<br />
| FE || Query parameters || 0 || Query all parameters<br />
|}<br />
<br />
=== Software ===<br />
I wrote a simple Arduino library to communicate with the module, send frames to configure the device and receive frames with measurement data.<br />
<br />
My software archive with a demo application for ESP8266:<br />
https://github.com/bertrik/hlk-ld303<br />
<br />
=== Firmware ===<br />
I soldered a connector to the SWD interface and dumped the firmware. No time/motivation yet to reverse engineer it.<br />
<br />
=== Serial interface ===<br />
The module communicates at 115200 by default. This is slightly fast for the SoftSerial library on ESP8266 and some incoming frames will not be recognised.<br />
<br />
In my demo application, you can discover the currently used baud rate using the 'autobaud' command.<br />
Then use the 'baud' command to set a new baud rate, this activates after a power-cycle.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=Galerij&diff=31749Galerij2023-10-23T11:59:12Z<p>Bertrik Sikken: </p>
<hr />
<div>Dit is het kunstplankjes beheersysteem. Elk half uur checken de infotags deze wikipagina en werken zichzelf bij. Handmatig resetten/powercyclen werkt ook.<br />
<br />
Instructie:<br />
* Heading 1 is de unique badge identifier (zet de badge nickname op deze titel). Verander deze niet!<br />
* Heading 3 is de projectnaam. <br />
* Maker: , Omschrijving: en Datum: op aparte regels en ze worden verwerkt in de code. <br />
* Plaatje ergens toevoegen, max 128x128. Kleiner gaat goed, groter zorgt voor afknippen (vertikaal) en crashes (geheugen vol).<br />
<br />
=Plank 1=<br />
===WIPcam===<br />
Maker: jij!<br />
<br />
Datum: 2018<br />
<br />
Omschrijving: Maak een foto van je Work In Progress (en andere leuke dingen) en deel automatisch foto's op de website. Vraag toestemming voordat je iemands privacy schendt!<br />
<br />
=Plank 2=<br />
===Energy-ring===<br />
Maker: bertrik<br />
<br />
Datum: 2022-11-13<br />
<br />
Omschrijving: Shows current Dutch electricity generation mix by source, YELLOW:Solar BLUE:Wind RED:Fossil GREEN:Nuclear PURPLE:Other<br />
<br />
=Plank 3=<br />
<br />
===Technisch Lego Beest===<br />
Maker: audionerd<br />
<br />
Datum: 2020-01-01<br />
<br />
Omschrijving: ik zat ooit te klooien met dat voorste interne tandwiel, heb de geometrie die bleek te werken doorgezet naar achter, het bleek een beest<br />
<br />
=Plank 4=<br />
===Uw project hier===<br />
Maker: Herman Acker<br />
<br />
Datum: 2019-01-19<br />
<br />
=Plank 5=<br />
===Steen en hout===<br />
Maker: Gori en Molenaar<br />
<br />
Datum: 2019-04-09<br />
<br />
Omschrijving: From Dirt To Space en Lichtenberg figuren<br />
<br />
=Plank 6=<br />
===Dinoboi Clock Behuizing===<br />
Maker: CH23 (Behuizing) Nikolett (Klok)<br />
<br />
Datum: 2023-10-07<br />
<br />
Omschrijving: Eerste 3D print naar eigen ontwerp.rood = 1 uur per LED, blauw = +/- 2.5 minuut per LED<br />
<br />
=Plank 7=<br />
===Waving Lucky Cat===<br />
Maker: jelly<br />
<br />
Datum: 23-09-2017<br />
<br />
Omschrijving: Cat waves for 10 seconds when someone watches cam 4.<br />
<br />
No touchy!<br />
<br />
=Plank 8=<br />
===Stempel===<br />
Maker: Sebastius<br />
<br />
Datum: 2020-01-19<br />
<br />
Omschrijving: Een eerste poging stempels te maken met de lasercutter. Speciaal 'laserrubber' aangeschaft hiervoor.<br />
<br />
=Plank 9=<br />
===Uw project hier===<br />
Maker: Herman Acker<br />
<br />
Datum: 2019-01-19<br />
<br />
=Plank 10=<br />
===Testobject===<br />
Maker: Sebastius<br />
<br />
Datum: 2018<br />
<br />
Omschrijving: Dit is een zooitje maar wel een goede test.</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=KatBeeldje&diff=31739KatBeeldje2023-10-21T18:32:14Z<p>Bertrik Sikken: </p>
<hr />
<div>{{Project<br />
|Name=KatBeeldje<br />
|Picture=whyunopicture.png<br />
|Status=Completed<br />
|Contact=Flok<br />
}}<br />
<br />
KatBeeldje is a project by [[Flok]]<br />
<br />
When booting, it flashes both eyes. If either eye is on while the blue esp-led is off, then it probably wants to reconfigure its wifi or it has crashed - in both cases powercycling will do.<br />
<br />
KatBeeldje was bought at [https://www.action.com/nl-nl/p/3201362/honden-of-kattenbeeldje/ Action] on 2023/10/21 by [[Bertrik]] at request by Flok.<br />
<br />
The eyes being drilled unevenly was not on purpose. The back of the head completely busted IS on purpose, also the ESP glued to it in an angle is on purpose.<br />
<br />
Please do NOT modify the hardware.<br />
<br />
If you really want to modify the software, please don't but if you really really really must do it: the leds are on D1 and D2 and the software is on GitHub at https://github.com/folkertvanheusden/KatBeeldje Also notify [[Flok]] of this misbehaviour of yours.<br />
<br />
Picture:<br />
<br />
[[File:P1050783.jpeg|640px]]</div>Bertrik Sikkenhttps://revspace.nl/index.php?title=NoiseMeter&diff=31678NoiseMeter2023-10-08T13:59:31Z<p>Bertrik Sikken: </p>
<hr />
<div>{{Project<br />
|Name=NoiseMeter<br />
|Picture=NoiseMeter.jpg<br />
|Omschrijving=Measuring audio noise as citizen science<br />
|Status=Initializing<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is about measuring environmental audio noise as citizen science.<br />
<br />
For example, noise can be:<br />
* road traffic noise (cars, mopeds, etc)<br />
* air traffic noise,<br />
* industrial noise, like building activities<br />
<br />
Existing sound/noise meter projects: <br />
* [https://github.com/meekm/LoRaSoundkit LoRa sound kit] by Marcel Meek<br />
* [https://github.com/hbitter/DNMS DNMS project] by Helmut Bitter<br />
* [https://gitlab.waag.org/lodewijk/amsterdam-sounds-kit Amsterdam sounds kit] from Waag Society, <br />
* Unknown sensor tested by RIVM in Schiedam (mentioned on https://www.samenmetenaanluchtkwaliteit.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein )<br />
* Sound meter by Bart Jurgens uit Amerongen, link ???<br />
<br />
This project is about a kind of clone of the Amsterdam Sounds project.<br />
<br />
== hardware ==<br />
=== Nano33 IOT ===<br />
[[File:nano33iot_pinout.png|thumb|right|250px|Nano33 IOT pinout]]<br />
<br />
Hardware is a nano33 iot board.<br />
<br />
{| class="wikitable"<br />
|+Connections<br />
|-<br />
!SPH0645!!nano33 iot!!Remark<br />
|- <br />
| SEL || - || leave unconnected<br />
|- <br />
| LRCK || A2 (16) - I2S FS || sample clock<br />
|- <br />
| DOUT || D4 (4) - I2S SD || data<br />
|- <br />
| BCLK || A3 (17) - I2S SCK || bit clock<br />
|- <br />
| GND || GND ||<br />
|- <br />
| 3V || 3v3 ||<br />
|}<br />
<br />
== Software ==<br />
The software is based on arduino, built using platformio.<br />
<br />
* [https://github.com/bertrik/AdamSoundsInflux-slim-nano-33 software repo]<br />
<br />
== Casing ==<br />
I'm looking into several options:<br />
<br />
=== Junction box ===<br />
Simple junction boxes sold by Gamma:<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-m20-met-3-wartels-ip65/p/B410376 and<br />
* https://www.gamma.nl/assortiment/attema-kabeldoos-ip65-3x-m25-m20/p/B306878 (IP65)<br />
<br />
A downward pointing hole can be used for an 868 MHz LoRaWAN antenna.<br />
<br />
=== Sensor.community casing ===<br />
See https://sensor.community/docs/dnms/dnms-noise-measuring-dn40-result.jpg<br />
<br />
Dimensions:<br />
* microphone is on a half inch (12.7 mm OD) white polystyrene pipe, 115 mm long<br />
* main piece is 25mm, length 160mm<br />
* some other connecting piecess<br />
<br />
=== "RIVM" test casing ===<br />
Exact dimensions unknown, see photo on this page: https://samenmeten.nl/nieuws/citizen-science-geluidmetertest-op-rivm-terrein<br />
<br />
My guess:<br />
* microphone is on a 10mm diameter pipe, length 100mm<br />
* main case is a 40mm diameter pipe, length 200mm</div>Bertrik Sikken