https://community.element14.com/challenges-projects/project14/Monthly Electronics & Design Project Competitions. Build projects around themes, submit video proof, and win free products regardless of level of expertise.en-USTelligent Community 12https://community.element14.com/challenges-projects/project14/f/forum/57217/reminder---show-tell-competition-closes-this-sunday/237995Wed, 02 Sep 2026 09:31:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:33f78b1e-cd11-4e17-b077-419dc7162549e14philHi, this project got auto moderated and was released. This will be included in the judging.https://community.element14.com/challenges-projects/project14/p/show-and-tell-your-electronics-projectsTue, 01 Sep 2026 12:44:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1d08ee81-2511-48f4-90bc-3bdb185635f3Competition Closed To Submissions - Winners will be announced 4th September Have you ever built an exciting electronics project but have nowhere to show it off? Share it on the element14 Community in our Show & Tell competition! It could be something you built previously in your spare time, at work, as part of your university studies, or something you are working on right now. All you have to do to be in with a chance of winning is write a blog and include all the photos, videos, diagrams, code, etc. that you can. How To Win To be in the running to win the prize, participants had to submit their project here as a blog: When writing your project entry, you will be expected to include: Your plan for your project, how it works and what it does, and what inspired you to build it. Document step-by-step how you built your project. Any interesting problems you ran into and how you solved them or worked around them. If your project is a work in progress, document what stage your project is at right now and what is working/not working, and what your remaining challenges are. Click here for a full guide on how to write a winning project blog. Below are some recent projects submitted by community members to give you an idea of potential layouts for project blogs and how you can incorporate images etc. into your blog: Important Dates Competition open for submissions 24th June - 30th August 2026 Deadline for submissions 23:59 UK time 30th August 2026 Winners announced 4th September 2026 Prizes shipped (estimated) 11th September 2026 If you have any problems with the element14 Community or engaging with the competition, please "Report a Problem" in Feedback and Support . About Project14 Competitions This is your opportunity to build an electronics project using just what you have lying around, what you can upcycle or purchase, and be in with a chance of winning a prize! Project14 competitions are lots of fun, no pressure, and a chance to share with like-minded engineers and makers across the world.https://community.element14.com/challenges-projects/project14/m/managed-videos/151685Mon, 31 Aug 2026 01:09:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:caa41e9b-ad28-46aa-9d95-c5750dc0c383element14 Communityhttps://community.element14.com/challenges-projects/project14/m/managed-videos/151684Mon, 31 Aug 2026 01:04:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0a8b15a5-d492-4bba-8896-ca4a7d03ac93element14 Communityhttps://community.element14.com/challenges-projects/project14/m/managed-videos/151683Mon, 31 Aug 2026 00:59:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:25ec5a0e-0f19-4847-a5e2-5da507016de1zso2khttps://community.element14.com/challenges-projects/project14/m/managed-videos/151682Mon, 31 Aug 2026 00:59:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:247649d7-ff30-472f-aed5-213e69625287zso2khttps://community.element14.com/challenges-projects/project14/m/managed-videos/151681Sun, 30 Aug 2026 23:32:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:05d862b3-d874-4744-99db-6b12f99fd337TheRehnhttps://community.element14.com/challenges-projects/project14/m/managed-videos/151680Sun, 30 Aug 2026 23:32:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:59c714ed-893c-4540-8115-96a7128997b1TheRehnhttps://community.element14.com/challenges-projects/project14/m/managed-videos/151679Sun, 30 Aug 2026 23:32:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:623a3c27-fc9a-43e6-a8a2-57ff4291d206TheRehnhttps://community.element14.com/challenges-projects/project14/m/managed-videos/151678Sun, 30 Aug 2026 23:30:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:69bcfbbd-f33e-48c1-b09e-826dd0bc2304TheRehnhttps://community.element14.com/challenges-projects/project14/b/show-and-tell/posts/ambient-led-heat-network-thermostat-user-focused-prototypeSun, 30 Aug 2026 22:59:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:48a334ad-7a76-4ac1-ba05-07892ce9f62fTheRehnEdited to get the videos and pictures to actually upload community.element14.com/.../video-1.mp4 I made this prototype for an Open University Interaction Design course using a Circuit Playground Bluefruit, an all-in-one micro-controller development board, with a built-in ring of neopixels. It was my first foray into working with micro-controllers and neopixels, so although it's not very electronics-y I thought I would share, especially with where I got stuck and could use some advice! The project was inspired by Heat Network Heating, which is a communual form of heating for a building or disctrict and particularly common in social housing. The heat network my building is on on actually gets the heat from the local harbour, which is pretty cool. However because of the communal nature it means that residents don't get a choice of heating supplier, the multiple sub-contractors managing it and the technologies in their home, and are often quite confused how it works. Alongside my own experiences, I spoke with people in my building and also looking at research from Citizens Advice Bureau and the Social Market Foundation , around consumer issues with heat network heating, which included issues with the controls and topping up and barriers around age, disability, digital inclusion and poverty, and the need for regulations being introduced. The focus of my module was users and interaction, rather than technology, electronics and coding, but textbook we used 'Interaction Design: Beyond Human-Computer Interaction' by Yvonne Rogers, Helen Sharp, and Jennifer Preece featured some electronics and maker projects, including the Lilypad Arduino kit that inspired me to try this! It was a bit of a learning curve. Looking at the users needs and barriers around thermostats being complicated and confusing I decided I wanted to make something that would reassure the user and help them understand what was happening with their heating and reduce stress, Making use of ambient lighting seemed to be a good way to achieve this. Initially I found a bluetooth controlled lighting strips, but it wasn't customisable enough to test and then I found NeoPixel strips and microcontrollers and I got a bit confused. When I saw the Circuit playground Bluefruit and saw that it uses Python I felt more confident I could make some with actual lights. There was a TFT screen with attachments ready to screw on as well, which meant I could even have a small screen in my prototype, which I hadn't considered would be possible when I started. It was really fun, I plugged in the Circuit Playground for the first time and the LEDs light up and animate all the colours of the rainbow. First I connected it to the Bluefruit Playground app, this is very limited, but was useful to see some of the different things the LED's could do and start to design how I wanted my lights. Then I followed the instructions to set it up to run CircuitPython, using an IDE called MU. A big challenge was working out what libraries I needed. The LED.animation library was great, most of the LED effects I wanted to set up I just needed to call a function from the library and adjust colours and timings and there were a couple that I made more manually. I experience migraines so one of the first things I worked out was how to reduce the brightness of the LEDs cp.pixels.brightness = 0.2 worked well for me. Another important thing I learned as a beginner was to use monotropic, which has to be set at the beginning, so that stopping the NeoPixels to animate them doesn't pause everything running. community.element14.com/.../Topping-up.mp4 My orginal plan was to use pictures for the screen designs and load them on, but I didn't account for the limited storage on the Circuit Playground Bluefruit, so I to make the screens in code. I used Google Gemini to help me make template to match my screen layouts and then was able to call the templates as a function with the content. This was actually so cool to use and prototype with, because I can so quickly adjust and change content or have different versions, so I think I will use this approach for other things too. One issue I found really irritating and haven't managed to resolve is the capacitive touch buttons on the front beside the screen are not very consistent or easy to use and I spent quite a lot of time trying to work out how make and add some form of buttons to the front to fit the form factor, but I got confused and overwhelmed with deadlines looming. Would love any suggestions of how I can learn more about how to do this as it's pretty important! community.element14.com/.../Setting-Temperature.mp4 Because the purpose of this prototype was to test the concept of the ambient LEDs with users, it was never intended to fully function. That said I would really like to explore making different light 'modes' and adding sound for accessibility. Having seen projects where people have made their own functioning thermostats, I would love to make a different prototype, ideally together with other local residents, focusing more on real data and interactivity within a home. This would allow us to test the impact, suitability and propose a more user and community-centred approach to heating controls. I have also been really inspired by the possibilities for NeoPixels for creative art projects and installations - it doesn't seem too intimidating anymore! As a designer I would really recommend to other designers to have a play and try making things, because it opens up a world of creative possibilities you may not have considered. community.element14.com/.../Budgeting.mp4https://community.element14.com/challenges-projects/project14/b/show-and-tell/posts/oled-system-monitor-for-the-uno-qSun, 30 Aug 2026 22:50:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:ee095747-a874-401b-b702-9eaa7955acd8veluv01Introduction For the last few weeks, I’ve had an Arduino UNO Q sitting on my desk, quietly running Hermes Agent. Most of the time it is not seen. No screen, no blinking lights that signify anything, just a small board doing work I can't see. Occasionally, I’d ssh in, run htop, stare at a wall of numbers, and close terminal again. It worked, but it never felt quite right. A machine that was actually doing something, thinking, responding, sometimes working hard enough to get warm, deserved better than a terminal window I had to remember to open. Hence , I added a small SSD1306 OLED display that was connected through I2C with the help of a Grove Base Shield and was in a position to show the CPU load, RAM, temperature, and network throughput on a rotating set of screens. What made this project interesting , however , was not just the display but also coming up with a way of distributing the workload onto the two very different processors of an UNO Q as well designing user interface which does actually deserve a space on a 128x64 black and white screen . Using the RPC Bridge The UNO Q has the looks of any ordinary UNO board, yet hidden inside this usual form factor is a pair of controllers sharing a single PCB. One is Qualcomm’s Dragonwing QRB2210 SoC that is capable of running full Debian Linux, while the other is STM32U585 microcontroller functioning according to Arduino sketch model. Hermes exists on the Linux side and this side has a real filesystem built upon Linux allowing the use of Python and package management. The two sides communicate with each other over RPC layer Arduino calls Bridge - therefore one can call Bridge.call() in Python and this call will be caught in the sketch with the use of Bridge.provide(). Overall, the first real design question was which side should own the display. Driving the display directly from Python seems like the easiest path, because there are many libraries that work with display, direct I2C access and absence of any RPC layer to bother about. However, I did not want to go this route, because the Linux side of the board has real tasks to carry out. Whenever Hermes is busy on doing something with the aid of Python code, that Python Thus, I changed the arrangement. The Linux's task is very clear: to poll psutil every second and tell it the values of the CPU, RAM, temperature, network throughput, and uptime. def loop(): cpu = psutil.cpu_percent(interval=None) ram = psutil.virtual_memory().percent temp = read_temp_c() net = net_kbps() uptime = int(time.time() - start_time) Bridge.call("update_stats", float(cpu), float(ram), float(temp), float(net), uptime) print(f"cpu={cpu:.0f}% ram={ram:.0f}% temp={temp:.1f}C net={net:.1f}KB/s") time.sleep(1.0) The display is completely under the STM’s control, which is rendering whatever is on its mind as the latest known values. Therefore, even if the agent is lagging behind the Python cycle by one or two seconds, the on-screen animation will continue working because drawing the pixels does not depend on the agent's work. In essence, the contract between the two processors is very simple: Bridge.call("update_stats", cpu, ram, temp, net_kbps, uptime) from Python and the handler that is registered through Bridge.provide_safe() on the other side. The _safe variant is important because it ensures that the callback runs in the main Python loop rather than some internal Bridge thread, so the handler can simply copy the values into some volatile global variables without worrying about possible race conditions. Everything that comes after that, the animation, the display rotation and the history, is up to the MCU only. Building the OLED UI Monochrome displays provide a different approach to design thinking than greyscale displays do. It does not include any shading or soft edges; pixels can either be on or off. Therefore, the solution lies not in some dithering tricks but instead in the good use of bold shapes and large white space instead of cramming in every single number into one dashboard. The dashboard consists of three rotating screens that change every 4 seconds, with each screen having its own identity. The Hero screen answers one question immediately: How much is the CPU currently working? A large table number displays the CPU usage percentage in the center. void drawHeroScreen() { int cx = 64, cy = 26, r = 22; drawArcGauge(cx, cy, r, g_cpu); char buf[8]; snprintf(buf, sizeof(buf), "%d", (int)g_cpu); u8g2.setFont(u8g2_font_logisoso18_tn); int w = u8g2.getStrWidth(buf); u8g2.drawStr(cx - w / 2, cy + 7, buf); u8g2.setFont(u8g2_font_5x7_tf); u8g2.drawStr(cx - 10, cy + 17, "CPU %"); drawSparkline(4, 52, 120, 12); } The percentage is encircled with an arc that completes its rotation (clockwise) as load increases – the function works similarly to that of a battery indicator. void drawSparkline(int x, int y, int w, int h) { u8g2.drawFrame(x, y, w, h); for (int i = 0; i any I2C port on a Grove Base Shield // stacked on the UNO Q. // IMPORTANT: the UNO Q's I2C pins are 3.3V-only (not 5V-tolerant). // If the shield has a 3.3V/5V toggle switch, set it to 3.3V before // connecting anything: leaving it at 5V feeds 5V to the OLED's // SDA/SCL pull-ups and can damage the MCU. #include "Arduino_RouterBridge.h" #include #include U8G2_SSD1306_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset=*/U8X8_PIN_NONE); // Latest values pushed from the Linux side volatile float g_cpu = 0, g_ram = 0, g_temp = 0, g_netKbps = 0; volatile uint32_t g_uptimeSec = 0; #define HIST_LEN 40 float cpuHist[HIST_LEN] = {0}; uint8_t histIdx = 0; unsigned long lastFrame = 0; unsigned long lastHistPush = 0; unsigned long screenSince = 0; uint8_t screen = 0; const unsigned long SCREEN_MS = 4000; // Called remotely by the Python side via Bridge.call("update_stats", ...) void update_stats(float cpu, float ram, float tempC, float netKbps, uint32_t uptimeSec) { g_cpu = cpu; g_ram = ram; g_temp = tempC; g_netKbps = netKbps; g_uptimeSec = uptimeSec; } void setup() { u8g2.begin(); u8g2.setBusClock(400000); Bridge.begin(); Bridge.provide_safe("update_stats", update_stats); } void pushHistory() { cpuHist[histIdx] = g_cpu; histIdx = (histIdx + 1) % HIST_LEN; } // --- Drawing helpers --- void drawArcGauge(int cx, int cy, int r, float pct) { float start = -HALF_PI; float end = start + TWO_PI * (pct / 100.0); for (float a = start; a 250) { pushHistory(); lastHistPush = now; } if (now - screenSince > SCREEN_MS) { screen = (screen + 1) % 3; screenSince = now; } if (now - lastFrame > 33) { lastFrame = now; u8g2.clearBuffer(); switch (screen) { case 0: drawHeroScreen(); break; case 1: drawVitalsScreen(); break; case 2: drawPulseScreen(); break; } u8g2.sendBuffer(); } } main.py # Runs on the UNO Q's Linux (MPU) side. # Polls system stats and pushes them to the STM32 MCU over Bridge. # Runs on the UNO Q's Linux (MPU) side. Polls system stats and pushes # them to the Arduino sketch (MCU side) over the Bridge RPC link. from arduino.app_utils import * import psutil import time start_time = time.time() _last_net = psutil.net_io_counters() _last_net_time = time.time() def read_temp_c(): """Best-effort SoC/CPU temperature in Celsius, 0.0 if unavailable.""" try: temps = psutil.sensors_temperatures() for name in ("cpu_thermal", "soc_thermal", "coretemp"): if name in temps and temps[name]: return temps[name][0].current for entries in temps.values(): if entries: return entries[0].current except Exception: pass return 0.0 def net_kbps(): """Combined send+receive throughput in KB/s since the last call.""" global _last_net, _last_net_time now_net = psutil.net_io_counters() now_time = time.time() dt = max(now_time - _last_net_time, 0.001) delta = (now_net.bytes_sent + now_net.bytes_recv) - ( _last_net.bytes_sent + _last_net.bytes_recv ) _last_net, _last_net_time = now_net, now_time return (delta / dt) / 1024.0 def loop(): cpu = psutil.cpu_percent(interval=None) ram = psutil.virtual_memory().percent temp = read_temp_c() net = net_kbps() uptime = int(time.time() - start_time) Bridge.call("update_stats", float(cpu), float(ram), float(temp), float(net), uptime) print(f"cpu={cpu:.0f}% ram={ram:.0f}% temp={temp:.1f}C net={net:.1f}KB/s") time.sleep(1.0) App.run(user_loop=loop)oledssd1306uno qgrovearduinoShow and TellGrove HAT