A brief foray into the Arduino Uno Q

Several years ago I developed a project that allowed me to use LoRa, some low power MCUs, and some nifty timers to create a series of weather sensors in the interior and exterior of my house (see Elektor project).

The system works quite well, but it is difficult to place the outdoor sensor optimally. Depending upon the time of day, it’s either in a perfect spot or overheating. For years, I’ve had an inexpensive Radio Shack temperature sensor hanging out of my bedroom window, which is pretty good for morning temperatures. It’s gotten unreliable with age and I decided to replace it.

Rather than adding another wireless sensor and receiving station for my bedroom, I planned to drop a wired sensor out of my window and connect it to a simple readout. I was making good progress on this project when I read about the Uno Q. 

For the uninitiated, this is an Arduino board that sports an MCU and a CPU and critically, software that permits the two processors to share information and instructions. I’m a pretty good Arduino programmer and a novice Python programmer, and I thought this might be an interesting slightly deeper dive into IoT-derived data handling.

The plan was to use the MCU to manage and collect sensor data. Using code I lifted from my previous project I was able to rapidly prototype the MCU side of the project. The MCU directly senses two BME 280 modules, one dropped out the window and one in my bedroom. It also manages a LoRa radio that allows me to monitor the existing wireless sensors elsewhere on our property.

The data as collected would then be passed to the CPU, which would be responsible for displaying the information. Potentially, collecting longer-term information and graphing trends of readings might be possible using Python graphics and data tools.

The UNO Q software environment is based on the Arduino App Lab (AAL). The AAL includes an IDE with a very bare-bones editor for Python and the Arduino C++ dialect. The AAL comes with a series of “bricks” for building applications. These are classes that simplify a wide variety of Python tasks. Finally, the AAL includes classes in both Python and C++ for data exchange. 

Briefly, functions are “exposed” to the bridge with a Bridge.provide() call. The MCU can call a Python function on the CPU and get the information generated by the function, and the CPU can call a C++ function on the MCU and get that information. Some parts of the bridge mechanism are pretty straightforward, but others, not so much. For example I could pass a C++ std::<array> to Python, which received it as a list. Huh? It works, but it was an unexpected construct.

Pretty nifty. 

I used the Streamlit brick as this looked pretty easy for a newbie to Python, and in fact it is, with a couple of caveats. The Streamlit environment is designed to create easy-to-use web-based dashboards. The Streamlit system runs its own event loop inside of the event loop created by the AAL for the Python part of the code. This made it impossible for me to call a Python function from C++ (believe me, I tried, did a lot of real research  on forums and formal documentation sites, and also allowed myself to be led around by the nose in circles by Gemini and Claude for a couple of mornings as I figured this out.) Since timing wasn’t critical, I was able to develop an OK workaround with the Python code calling the MCU. (More on timing in a moment.)

Bare metal Streamlit ain’t pretty, and has limited configurability. However, it gets the job done. As I got more comfortable with the environment, I played with plotting (works well, albeit slow) and added Pandas to explore further data storage and potential future processing. Again, once I learned about the limits of Pandas I was able to create code that would allow me to store and manipulate data. I didn’t pursue this, but left the stubs in my code for those who might have some interest in going futher. Pandas is a nice package. It works well, has coherent and comprehensible naming conventions, and is well-documented.

I added an LED time display driven by the MCU; after all, this was going to sit on my nightstand. Bridge calls from the CPU to the MCU are slow and interfered with my ability to blink the colon between the hours and minutes every second. While I would be able to use Streamlit to create an alarm function, the displayed day/time pickers were very small and could not be enlarged without considerable web-based coding, which is not my thing.

I did a couple of interesting things on the MCU side; I modified SparkFun’s BME 280 library so that at instantiation you can tell the MCU you’ll be using Wire or Wire1 (Wire goes through the Qwiic connector and Wire1 is exclusively pin-based.) I also used a very useful board from Adafruit, an LTC4311 breakout that allows extension of the physical length of an I2C connection (I’m using almost a meter of wiring with no complaints or missed data.)

On the CPU side, it’s a Debian distro. Using the board as an SBC, it feels about the same speed as an RPI4; definitely not an RPI5. I did not try anything particularly fancy, but it has a browser, the AAL, etc.

The IDE is underwhelming and feels a bit beta. Editor functions are very limited (e.g., no search and replace, no Control-T to format the C++ code). It does provide suggestions for auto-complete, which is sometimes helpful, sometimes bothersome. It appeared that I could only add a library from the list provided by Arduino. I had to add the .h and .cpp files to the project, rather than import the library, to use my BME280 variant. On my PC, the AAL app itself is, as my British friends might say, a bit fiddly. Python error messages often ended up on the Web page put up by Streamlit. If I allowed the PC to go to sleep, I often needed to quit and restart AAL to regain control of the application.

I tried using the Media Carrier. I reviewed the data sheet and purchased the appropriate WaveShare screen, which appears to have been defective. Problems with the display notwithstanding, the software connection to the carrier seemed to leave something to be desired.  The AAL requires that access to the media carrier be turned on in settings; the carrier does not seem to be handled as a standard display output. This may be my doing, but when I turned on display via media carrier, I was not able to use the HDMI output from the attached USB dongle--the board would not permit two displays. I am going to look at the Media Carrier again, perhaps when the software is updated. Ability to use that add-on would make the Q much more attractive.

OK, so maybe some of the other bricks work better. I hope so. Streamlit seems to have some specific issues that may make it a less than perfect match to the UNO Q environment, and maybe that should have been explained better.

From a final, finished project standpoint, one more point. The Bridge uses high-speed serial communication. As soon as I added all my peripherals—the radio, the sensors, the indicator LEDs, the time display—I lost the advantage of a single board, which admittedly is quite significant. Once I am using a peripheral board, why not use a Nano Matter or a Teensy? The incremental benefit of a single board is lost except for the Arduino footprint and the ability to use hats. From a programming standpoint, it would take an equal (if not lesser) amount of intellectual horsepower to write UART-based data-sharing routines and skip the Bridge stuff. I think in terms of IOT applications and creating an end-product box that goes on a wall or desk, this might be an important consideration.

Overall, I think the board has considerable potential. I was attracted to it immediately when I read about it. However, I think better documentation and better editor functions in the IDE are needed to take advantage of the board's potential.

I would be interested in and would welcome comments, respectful criticism, and rebuttal.  I’ve included a couple of pictures of my setup and the exported AAL app. I did not include a schematic. The wiring is straightforward using only standard breakout boards and a few LEDs. (If there is a wild outpouring of enthusiasm for this project, I can put something together.) I use four indicator LEDs primarily for development; they light up when receiving data. A more complete explanation of some of the LoRa related functions can be found here: https://www.elektormagazine.com/labs/low-power-lora-weather-station 

AI disclosures: I use Grammarly routinely for punctuation, tenses, and to improve particularly abominable phrasing (like this one.) Claude and Gemini were used for assistance with understanding Pandas and Streamlit and to insert a healthy dose of confusion and random, partially correct information. All code and this article was written by me, either as original code, modification of example code, or  modification of preexisting libraries.