https://community.element14.com/technologies/internet-of-things/The Internet of Things (#IoT) becomes a popular industry topic and data illustrating perspectives are very impressive: IHS predicts 29.2 billion of connected devices by 2020. Huge opportunity! Let's discuss about technology, market trends and solutionsen-USTelligent Community 12https://community.element14.com/technologies/internet-of-things/b/blog/posts/low-power-wireless-building-an-outdoor-transmitterSun, 30 Aug 2026 19:21:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c44f435d-255d-43ec-b3bc-f6ac1b496a19shabazTable of Contents Introduction Beep Sensing Digital Sensing Transmitter Circuit Microcontroller Circuit Putting It All Together Software Overview Awake Phase Receive Phase Sleep Phase Radio Driver / Protocol Transmit Packets Receive Packets User Menu Power Measurements Next Steps / Premature Project Post-Mortem Summary Introduction A friend had a need to monitor an outdoor device; it’s related to a watering system, and the output is a beeper. Unfortunately, the beeper is only loud enough to annoy the neighbors, but not loud enough to hear indoors! Definitely not fit for purpose. The requirement was to somehow hear that alert indoors, and disable the outside beeper! This blog post documents how I went about trying to solve this problem. There is no full project repository, it was a one-off circuit that ought to be redone significantly to improve on all the issues I found. There are plenty of bodges on the PCB, but I cannot see myself respinning this without majorly rethinking a lot of the circuit. However, the circuit I used is pasted within the blog, and all the (hopefully easy-to-port) code (the radio driver) is in a repository (it uses a custom 12-byte protocol). There should be enough information here so others can see what to do and what not to do, to improve on this project and not make the mistakes I did. Beep Sensing I have no access to the watering system, I have not seen it nor measured anything, so I was working somewhat blind when developing this solution. The circuit below shows what I used for the beep sensing, and since it is all done in the analog domain rather than in a microcontroller, it is easy to simulate if anyone is interested. The output is a voltage level that is representative of the amplitude of any incoming beep. Here is the simulated frequency response of the first stage: The ‘scope trace here shows the PEAK_OUT output, when the input (TONE_IN) is 0V. If I apply a 100mV p-p 1 kHz signal (yellow) at the input, then the output (pink) rises to about 0.45V. This is therefore quite a large output signal, easy to measure by the microcontroller ADC. I need to support a large input range, because I have no idea what the system that this circuit will attach to will output. If I apply a very large signal (5Vp-p, orange) at the input, I see a level of 1V output (yellow). Apologies for the inconsistent and wild colors, I’m still getting used to the reference traces in the new version of the PicoScope software. Digital Sensing This part of the design was probably unnecessary, but I did it anyway, in case some future use comes up. By using a comparator, I can modify the levels/thresholds for unusual/unexpected scenarios. The configuration currently sets the output (DIG_OUT) at a low voltage when DIG_IN is below about 0.6V. DIG_OUT goes to approx. 3.3V when DIG_IN exceeds 0.8V (approx.). Transmitter Circuit I decided to use the classic Texas Instruments CC1101 ( PDF datasheet ), which is available in module form. I had two good reasons: (1) The CC1101 has a very good level of configurability, useful if the project ever needs to interwork with different transmitters/receivers in future and (2) I was already using the CC1101 in another project so I reused my code. The module that was used was Ebyte E07- 900MM10S (900 MHz) although technically the 433 MHz version might offer longer range. As it is, the 900 MHz version will easily cover the largest of gardens and residences, unless one owns a farm or castle. There’s a spare output pin on the CC1101, I connected that to a blue LED to indicate transmissions! If I were to redo the project, I might give stronger consideration to using LoRa; there is an eByte LoRa module which is near-pin-compatible, but needs a few more signals. The modules are low-cost, one could even add both LoRa and CC1101 modules in a more future-proof design. Microcontroller Circuit This part of the circuit was the most challenging from my perspective, because I wanted it to be easy-to-use and configure, while at the same time being reasonably low-power. These requirements cause conflicts, because configuring a low-power circuit might not be possible when circuitry is asleep! What I came up with is shown in the circuit below (click it to enlarge). It is mostly modelled on the EasyL1105 circuit. The power to the entire board comes from the USB connector, or from a 5-15V external source, and a diode (D3) protects the USB interface from receiving current from the 5-15V source. The MSPM0L1106 microcontroller has two UART interfaces, one of which, known as BSL, can be used to update the firmware. I used the other UART, known as UART0, to implement a configuration menu. A multiplexer/demultiplexer IC, U3, is used as an electronic switch to choose which of the two interfaces (BSL or UART0) should connect to the USB UART chip (U2). I wanted to eliminate the need for button-presses and jumper connections, so the *RTS and *DTR lines are used to try to reset the microcontroller, and to put it into boot mode. I was only partially successful. As the circuit stands, it is certainly possible for a user to reprogram the chip by simply plugging the USB connector to a PC, and running mspm0_programmer software. That works great. However, the microcontroller needs to be restarted manually (either press a button, or power-cycle). That’s not good, but I’ve accepted it and moved on : ( Another issue is that with this circuit, the user cannot use any arbitrary serial terminal software to access the UART which runs a menu system. The serial terminal software must support the disabling of *DTR. TeraTerm is suitable, but others such as MobaXterm are not. In reality this is not too much of a problem, because I don’t expect users to use serial terminal software. I expect users to access the configuration through a custom graphical interface. The direct serial terminal menu is more for the advanced user. Putting It All Together The block diagram here shows how all the sub-circuits connect. The driver block at the top-right is unimportant, that’s just a MOSFET for optionally driving things in the future. Software Overview I decided to have three configurable parameters which define the periods for three important phases of the program operation; awake, receive, and sleep. Awake Phase During the awake time, the microcontroller can check the digital input, and perform ADC measurements, and if a threshold has been exceeded, then the radio module can be briefly set to transmit mode, to send an alert. When the microcontroller begins the awake phase, it can send an empty radio message if there is no immediate alert to send. Receive Phase The receive phase overlaps the awake phase, they both commence at the same time, but the receive phase expires sooner. The indoor receiver will be aware that the outdoor sender has just woken up because it will have seen either an alert packet, or an empty packet. This is therefore a good time for the indoor receiver to transmit any new config if desired. As mentioned, the receive period starts when the awake period begins. The CC1101 is mostly in receive mode during that time, in case the indoor receiver wishes to transmit anything. After the receive period expires, but before the awake period expires, the code continues to check the ADC measurements and digital input, in case the CC1101 needs to be powered up to transmit an alert. Sleep Phase When the awake period is complete, the microcontroller powers down circuitry, sets a timer and goes to sleep. The digital input, and a button on the board can be used to wake up the microcontroller if desired before timer expiry. Radio Driver / Protocol The project uses a CC1101 simple driver that is generic, it should work with any microcontroller. The CC1101 is configured to use GFSK modulation at a slow bitrate, since only 12 bytes of application data are used (I figured that would be sufficient for my needs). The 12 bytes contain a destination station identifier, version number, sequence number (so that packets can be repeated for a bit more reliability), a parameter identifier, and 4 bytes for the value. Byte 0..1 : station_id (big-endian) Byte 2 : flags/version Byte 3 : sequence (useful to repeat packets for reliability) Byte 4..5 : parameter_id (big-endian) Byte 6..7 : reserved (big-endian) Byte 8..11: value (big-endian) If I were to do it again, I’d put more thought into the protocol. Perhaps change the parameter and value bytes into a more generic payload. A source identifier, and a packet type field would be a lot more flexible, and make it almost Ethernet -like (the CC1101 already adds preamble and a checksum). There are existing protocols such as LoRaWAN (if I’d used a LoRa module), but I felt that was excessive for the application, and it requires more infrastructure. Transmit Packets Four different parameter identifiers are used in this project: Parameter ID Description Trigger Alert Used to indicate if a threshold has been exceeded Supply Alert Used to indicate if the supply voltage is out-of-range (one of the ADC channels is attached to a potential divider wired to the supply input) Button Alert A user has pressed the button on the PCB Idle Packet Sent upon awake, if no other packet needs to be sent Receive Packets In ordinary use no packets are expected to be sent from the indoors unit to the outdoor unit. However, I felt it worthwhile to allow configuration of all important variables, perhaps useful when initially setting up the system. Plus, the circuit board has a single Open Drain general-purpose output, and in future one might want to activate that remotely. I randomly chose some parameter IDs, and used them for: GPOUT control, awake/receive/sleep interval setting, ADC thresholds setting, trigger mode (ADC and/or digital input) setting, station identifier and RX/TX frequency setting. So, in theory, the indoor unit can be used to tweak the outdoor unit settings, although in practise for the simple scenario that it is actually going to be deployed in, I’d expect the user to configure the outdoor unit settings using a USB cable plugged directly into the outdoor unit. Depending on the microcontroller or hardware, it could be possible to store the configuration parameters in non-volatile memory; that’s what I did with the MSPM0, since it has a lot of Flash storage space. User Menu The unit has no display, and no essential buttons. The USB interface can become the primary method to configure the unit (although, as mentioned above, the radio interface can do that too). A limitation in the current design is that the microcontroller needs to be awake to access the user menu. It is easy to see that the microcontroller is awake because of on-board LEDs, or, the user could power-cycle the board and then immediately connect. The menu uses GET/SET commands (e.g. SET awake_interval=600 ). However, the actual end user/installer is not an engineer, therefore I don’t expect them to fire up a serial terminal on the PC. Instead, they can use the AnyOperate app I worked on recently, for just this sort of scenario. It’s really convenient; using Android (for now; I don’t have a Mac to do the conversion for iPhone), one can connect to the outdoor unit via USB (or via USB, BLE or WiFi if connecting to the indoor unit) and configure it all from there. I’d like to modify that app to automatically pull templates from the web one day (that way the graphical display can be highly customized per project); today, all the config parameters are listed in a simpler manner (see the screenshot below) and the user just taps to select and modify. If you’ve got projects that are hard to configure or monitor for users, it could be worth giving AnyOperate a shot, and if you don’t like it, please suggest new features. There is a lot that could be done to improve it; so far, the software supports just some basics. Power Measurements For the intended use-case, I was not too concerned about making the project ultra-low-power; there is a solar panel plus battery outdoors, or alternatively, alkaline cells could be used; 4 x C cells might easily support a year of operation, i.e. $10 per year battery cost (and there’s no particular need for small size). Here’s what I measured (at room temperature; it could be very different outdoors!): State Current (mA) Awake and transmitting and sensing 49 Awake and receiving and sensing 27 Awake and sensing 5.6 Sleeping 0.195 The 195 uA sleep current can be broken down into: Circuit Current (uA) Source voltage monitoring potential divider 20 LDO (3.3V Regulator) 95 Microcontroller and associated connections 80 In theory, the sleeping microcontroller should only consume about 1 uA I believe, however there is some current that will leak through some of the connections, plus, I may not have fully shut down all unused features, although I attempted to. Sometimes, the lowest current consumption in sleep mode isn’t the bottleneck for decent battery performance. For the actual use-case for this project, if anything, it is the “sensing” current (guesstimating perhaps 4 mA, of the “awake and sensing” figure above) which will provide the greatest performance impact if that can be reduced further, because I believe the unit may need to be sensing for about a minute before sleeping for (say) 10 minutes, in case the tone alert that needs to be sensed only occurs once per minute (I am guessing). Next Steps / Premature Project Post-Mortem The circuit needs to be deployed : ) however, that’s unlikely to occur for a month or so. In the meantime, I will occasionally tweak the circuit or software, and leave it running from time to time. It’s hard to know if the project was a success or not until it’s been in the field, however, some conclusions can already be made. The main things I’d change are: (1) I don’t like JST PH connectors, the cables are unreliable without a ratchet crimping tool (the non-ratchet PA-09 tool is not really fit for purpose), and reliability is quite important for an outdoor project. The only reason I chose to use JST PH is because the existing system used that, and it would be handy to simply unplug the speaker and attach the cable to the transmitter. (2) I’m not sure how wise it is to have USB connectors outdoors. That might become a big failure point (thankfully it is possible to configure over the radio, if that connector fails, although new firmware upgrades would become more difficult in the field). If this were a commercial project, I'd consider putting the USB connector on a separate PCB, so that it could be swapped out easily if it ever fails. (3) I’d possibly use a different USB Serial chip; the CH340K ( datasheet download link ) has some quirks (see the discussion in the EasyL1105 blog; plus, you can see from the circuit diagram that I resorted to extracting a 3.3V supply from the chip, which is probably OK but technically unsupported) however there’s a learning curve with any new chip, and no guarantee everything would work first time with any other chip either; I’d also possibly consider just fitting two USB-C connectors and two USB Serial chips, one for firmware updates and the other for the user menu. (4) Ultra-low power was not an initial consideration, but if I were to redo the project, I might look for a LDO with shutdown capability, or lower current operation. (5) I’d focus more on the sensing circuit, to reduce the 5.7 mA current consumption in the “awake and sensing” mode; one simple low-hanging fruit change could be to separately enable power to the digital sensing portion, since mostly either ADC or digital sensing will be configured by the user, not both. (6) It would maybe be better to use a PCB antenna, and have one less connector to fail. Summary An outdoor transmitter was designed, which attaches to speaker outputs, and detects alert sounds, and transmits the alert signal to an indoor unit. The very popular CC1101 transceiver chip was used (in module form) along with a low-cost MSPM0 microcontroller. The radio protocol provides just a few bytes of payload. The protocol implements sequence numbers for increasing the reliability. The radio code is on GitHub , hopefully useful for any project that needs to transmit/receive a few bytes. A user menu system was implemented, and made (hopefully) easy-to-use with a mobile phone app (AnyOperate; Android releases are available from the project repo ). The software phases have configurable values for awake, receive and sleep periods, plus configurable thresholds for sense alerts and supply voltage faults. Thanks for reading!MSPM0easyL1105https://community.element14.com/technologies/internet-of-things/f/forum/57202/on-device-fine-tuning-in-608-bytes-gravoptmini-optimizer-w-twin-health-monitor-for-stm32Mon, 17 Aug 2026 23:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:b876e23a-f8bb-4ad7-ae88-42497b6bde00regdredBuilt a minimal on-device training stack for STM32 — fits in 608 bytes RAM total. The problem: Adam optimizer needs exp_avg + exp_avg_sq — 2× parameter RAM. On STM32F103 (20KB SRAM) with a 5K parameter model that's 40KB just for optimizer state. Doesn't fit. What I built: GravOptMini — momentum optimizer with quantile-based gradient freeze. Only exp_avg (1× param RAM). Freezes low-gradient parameters to reduce compute. W-Twin Lite — power-law baseline fitted on early steps, tracks deviation. Pure float32, no scipy, no numpy. Rolling window of 20 values. ~240 bytes. Benchmark (Python simulation, STM32 memory constraints): - Model: 46 params, 184 bytes - GravOptMini state: 368 bytes (exp_avg only) - W-Twin Lite: 240 bytes - Total: 608 bytes - MNIST accuracy: 93.2% vs Adam 97.4% - W-Twin overhead: 3.9% per step - Detection: anomaly caught 96 steps before visible loss divergence, 0 false alarms on clean run Next step is a real STM32 test with physical hardware. C port of both components is the plan. Has anyone done on-device fine-tuning on STM32? Curious what optimizer you used and what constraints you hit. Code: github.com/Kretski/WTwinedge aitinymlembeddedsystemsstm32optimizermachine learningioton-device learninghttps://community.element14.com/technologies/internet-of-things/b/blog/posts/mspm0-opamp-interconnectionFri, 14 Aug 2026 11:04:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2543e862-7cae-4a19-8faa-b7d77ad69d6dJan CumpsSeveral MSPM0 controllers have more than one OpAmp on board. There are MUX settings to interconnect them. I couldn't find a generic picture of how two OpAmps can be wired up, so I made one. It's based on Figure 17-8. Two OPAs in Difference Amplifier Configuration of Texas Instruments Technical Reference Manual for the MSPM0 L-Series 32-MHz Microcontrollers. click for full size Some connections aren't drawn, but have a label name. Comment if you 'd like to see some of them as a line.MSPM0https://community.element14.com/technologies/internet-of-things/b/blog/posts/mspm0-sample-photo-diode-with-internal-opamp-and-adcFri, 14 Aug 2026 08:30:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1d6f8951-2328-4895-aaf8-ae634902ac9bJan CumpsWhen you try to measure light intensity with a photodiode, you have to build some circuitry around it. There are several ways to do that. In this post, I'm investigating TI's application note MSPM0 Subsystem Design Transimpedance Amplifier . This is an interesting circuit. Because the OpAmp clamps the diode voltage to 0 V (same value as positive input), the only way the energy in the diode can escape, is as current. That current has to come from the output, via the feedback resistor (it can't come from the OpAmp input, because that's the same level as the other side of the diode: ground). That also means that the output has to be a higher voltage than ground: ground + (current * resistance). And that's something the ADC can then measure. See here for a better explanation. The OpAmp used in this design is one of the two that are embedded in the MSPM0 silicon. They are rail-to-rail chopper types (TI calls them zero-drift, zero-crossover chopper operational amplifiers). The microcontroller gives you control for: multiplexing in- and outputs (to pins, references, DAC, ADC, each other) a set of voltage reference sources to use (including that DAC) optionally a number of preset gains bandwidth, chopper on, rail-to-rail on, ... In the photodiode design, we use the OpAmp in a very classic way: the in- and outputs are routed to external pins chopper off programmable gain off rail-to-rail off high bandwidth (TI uses different setting in the transimpedance example and the out-of-box source. I used the settings of the latter) The feedback loop is built up by external components (see schematic drawing at the top of this post). TI has done the homework to specify them based on the specs of the Vishay VEMD4110X01 that's mounted on the launchpad. The capacitance of the diode is dependent on the voltage over it. In our case, there is 0V over the diode, and capacitance in that case is 5 pF. The max current is in the low single digit µA. Let's assume that the diode generates 1 µA. With the 2.37 MΩ resistor in the feedback loop, that would give an OpAmp output of 2.37 V. The rest of the design is uneventful. The MSPM0 ADC input is muxed to the same pin that's connected to the OpAmp output (there is an option to mux it internally on silicon too). The reference voltage is VDDA (analog VDD, on this launchpad the common 3.3 V). The ADC is set to single shot mode, and gets triggered by one of the timers. That's all.MSPM0photonhttps://community.element14.com/technologies/internet-of-things/b/blog/posts/august-12th-eclipse-can-i-measure-itTue, 11 Aug 2026 09:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:68745365-b70e-4970-bdc4-5441f5cedf2dJan CumpsTomorrow there's a solar eclipse. In Brussels, it's a partial one. 90%. I'm going to try and measure the light intensity during that event. image source: https://www.timeanddate.com/eclipse/in/belgium/brussels?iso=20260812 Google AI: In Brussels, the Moon will obscure 89.5% of the Sun’s surface (with a peak magnitude of 0.911 ) during tomorrow's solar eclipse on Wednesday, August 12, 2026 . Exact Local Timeline for Brussels (CEST) Because the eclipse occurs right before sunset, timing is critical: 7:18 PM – Eclipse Begins : The Moon first touches the edge of the Sun. 8:13 PM – Maximum Coverage : The peak of the deep partial eclipse occurs. 9:09 PM – Eclipse Ends : The event concludes just minutes after the Sun dips below the horizon. I'm going to use TI MSPM0 Launchpad. The kit has a light sensitive diode. And the controller (MSPM0L1306) has a good analogue front end. Current status: do everything :). I don't have the code yet. But I did check out the schematics for the light sensor. What I'll probably use: that light sensitive diode one of the OpAmps available on the L1306 ADC Timer UART I'll have to use the OpAmp as Transimpedance Amplifier . It 'll also have to bias the LED circuit. Luckily, there are examples . I have done this exercise before in 2015, with a Hercules Launchpad. That time, I also took a photo of the sun every so many minutes. It was a clouded day... If I manage to get my design working this evening, I'll share the findings in our community. Update the day after: it worked. Berfore the eclipse stated, I put my launchpad in a location that 's not directly in the sun: I made a design based on TI's Out Of Box example and that application note for transimpedance amplifiers. It did an excellent job - although the photodiode has a daylight blocking filter. There is a measurable component of IR in sunlight, so we are able to measure that. Here is a graph showing the measurements. start: 19:05 end 21:15 The eclipse happened when the sun was about to set. That's why, after the eclipse, you see both the effect of the end of the eclipse, and of the sun dropping behind the horizon. Google AI: In indirect sunlight, the percentage of energy between 800 nm and 1000 nm ranges from 4% to 13% of the total spectral energy . Widening the wavelength window to 200 nm captures a massive portion of the near-infrared (NIR) spectrum. In standard, direct global sunlight, this specific band is highly energetic, accounting for exactly 15% of the sun's total energy (providing about 150 W/m² out of the standard 1,000 W/m² solar baseline). However, just like the narrower band, indirect atmospheric scattering changes these numbers. 1. Clear Sky Indirect Sunlight (Open Shade): ~4% to 6% If you are standing in the shade on a perfectly crisp, cloudless day, your light is coming entirely from the blue sky. The Atmospheric Filter: Because Rayleigh scattering only affects shorter wavelengths (UV and blue light), the long 800–1000 nm infrared waves pass straight through the atmosphere without bouncing into the shade. The Result: The light is heavily depleted of infrared. Even though the window is wide, the 800–1000 nm band only makes up a small fraction ( ~4% to 6% ) of the ambient shade light. In the comments below, I posted a few action photos. Thank you for reading along.MSPM0eclipsesolarlaunchpadhttps://community.element14.com/technologies/internet-of-things/f/forum/57151/i-built-micropidash-real-time-web-dashboard-in-under-20-lines-of-micropython-no-cloud-no-frameworkTue, 04 Aug 2026 17:52:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:94854de6-6644-406c-aae4-1db42b05f13eKritishBeen building IoT projects every day for my #100DaysOfIoT challenge and kept running into the same problem — monitoring sensor data from ESP32/Pico 2W in a browser was always a mess. So I built micropidash. real-time web dashboard in under 20 lines of MicroPython. No cloud, no framework. Just shipped v2.0.0 with live sensor graphs — tested with DHT11 on Pico 2W, temp + humidity updating in the browser over WiFi. pip install micropidash github.com/kritishmohapatra/micropidash Would love feedback if you try it!element14 communitymicropythonraspberry pihttps://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237530Fri, 24 Jul 2026 12:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d0a7e6f8-86c1-43ec-91de-42f16d3e983bmichaelkellettThe FP6277 is a boost converter - not a battery charger. You don't need a booster to charge a Lithium Ion battery from USB - just a charger control chip. https://www.adafruit.com/product/259 https://www.amazon.co.uk/Lithium-Battery-Charging-Protection-Functions/dp/B08DQXPNR1/ref=asc_df_B08DQXPNR1 You could then connect the Pico directly to the battery. https://randomnerdtutorials.com/power-raspberry-pi-pico-6-different-ways/#batteries I haven't tried or tested any of the above. I suggest that you do a good bit more web research before spending money. MKhttps://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237529Fri, 24 Jul 2026 11:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d569f81e-89aa-444c-b316-86fe353b57c4GeoForemanHi, Sorry for being a noob. I want to start with the charging unit, I am using FP6277 as charger / booster, I want to connect the 3.7v 4000mA battery to the FP6277 and raspberry pi pico 0 : RP2040, in such a way that it it can charge the battery while connected to usb port and run and boost the voltage as necessary even without connected to USB. It would be helpful if you can send me a schematics so that I would have an idea. I need to see the connection how it is connected also to pico ports. Thanks.https://community.element14.com/technologies/internet-of-things/f/forum/57122/re-power-connection-problem/237528Fri, 24 Jul 2026 11:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a0ebe7c2-23c4-48ac-bb83-0a77643ff39dGeoForemanThanks I will draw it.