- A Sensirion SHT31-DIS-F temperature/humidity sensor, with PTFE membrane protection.
- A Sparkfun Qwicc connector, allowing access to a large variety of sensors, LCDs, relays and more, via I2C.
MCCI has added support for the Nvidia Tegra Jetson Nano XUSB device controller to the MCCI USB DataPump®. We support the full feature set of the XUSB IP block, including bulk, interrupt and control transfers, including superspeed, high speed and full speed operation. Combined with MCCI’s UVC 1.5 support, multi-stream support, and multi-function support, this makes an excellent platform for implementing advanced webcams. The DataPump allows zero-copy video streaming data paths, for maximum throughput. High-level APIs separate kernel and user mode functionality cleanly and efficiently.
As part of our IoT development work, MCCI and NY Passive House have been partnering to reduce the cost of monitoring buildings (both high performance buildings and conventional construction). This low-cost study identified eight-fold differences in energy intensity across a variety of buildings. By choosing buildings at the same altitude and in the same microclimate, we are able to focus on differences in construction.
We started monitoring electricity use and temperature a few years ago, using MCCI’s Model 4811 remote power meter with LoRaWAN® technology. This meter allows us to retrofit existing buildings with high-accuracy real-time power monitoring, without requiring Wi-Fi, cellular, or wired connections. We combined that with MCCI’s Model 4822 and 4832 indoor and outdoor environmental sensor.
The data we got was pretty comprehensive for the Passive House buildings, because they only used electricity. But we wanted to compare to more conventional buildings in the same micro-climate and ecotome. For that, we needed cost-effective ways of monitoring fuel oil and propane consumption. MCCI’s engineers responded with two new products, now in test in several buildings around Ithaca, NY.
- The MCCI Model 4861 Propane/Natural Gas meter combines an MCCI Catena® 4612 or 4801 LoRaWAN sensor with low-cost meter with pulse output.
- The MCCI Model 4871 Fuel Oil meter combines a 4612 or 4801 with a high quality fuel oil flow meter. (Not all flow meters are alike, and we want to be sure not to damage the boilers at our study sites. There are a lot of counterfeit flow meters of unknown quality on the market. After some research, MCCI selected high quality meters from Aichi Tokei in Japan, and sourced them directly from the factory.)
We run the data through our normal server (our open-source “Docker IoT Dashboard“, using a Node-RED / InfluxDB / Grafana pipeline). We installed in early February and were immediately getting interesting data. Installation was done by our local HVAC team, Hubbard Heating and Plumbing; MCCI provided diagrams, and Hubbard did the rest. It took between one and two hours per installation. The cost per meter was about $300 for equipment. To simplify installation, all meters use primary batteries only; part of the study is to determine battery life, but we are estimating one to two years, transmitting data every six minutes. We’re using The Things Network in Tompkins County, NY; so we didn’t have to set up a network and data charges are not a factor.
We instrumented three sites, “Comp 2”, “Comp 3” and “Comp 4”. (We also have a “Comp 1”, but for logistical reasons we’ve not added full energy capture there yet.)
- Comp 2 is a 1900-sq-ft farmhouse, built in 1847. It has a low-pressure steam heat system fired by fuel oil. Propane is used for hot water, cooking, and a clothes dryer.
- Comp 3 is a 1200-sq-ft bungalow, built in 1970. It has forced-air central heat fired by propane; propane is also used for hot water, cooking and a clothes dryer.
- Comp 4 is a 5900 sq-ft commercial building. It is an older building that was gutted and reconstructed in 200. It’s not insulated to Passive House standards, but is reasonably tight. It has zoned hot-water baseboards, with a boiler fired by fuel oil. Hot water also is provided by the boiler. Only limited cooking is done at the facility, and there’s no propane.
Fuel Oil Raw Data
Let’s start with the raw data. Here’s seven hours of fuel use at Comp 2:
It can be pretty cold in Ithaca in February; the temperature didn’t get above freezing all day. This is all data from Feb 4, 2021.
As you can see, the control system runs the pump for about 15 minutes, pauses it for maybe 5 minutes, and then runs for another 15 minutes. Remeber, this is a low-pressure steam boiler; when the burner comes on, it has to run for a while to start driving steam into the pipes.
You can also see a repeatable pattern: the pump pushes a little more oil at the start of a burn cycle than at the end. We’re not sure why that is, fuel oil pumps are supposed to push at a constant rate. This is exactly why we wanted to see “actual fuel burn” rather than “pump-on time”.
Let’s look at “Comp 4” next. It has a baseboard hot-water system (not steam) and the operating pattern is completely different. Same time scale as above.
Notice that the pump is only on very briefly, about a minute at a time (except occasionally). We actually are checking with the HVAC engineers, because this looks like a broken control system – we think it should not be doing this. The variation in max flow is due to the fact that our totalizing sample rate (1/minute) is very close to the on/off cycle time so there’s a little bit of aliasing. The peak flow is 4.5 L/m, as compared to around 3.2 L/m at Comp 2.
Propane Raw Data
Let’s compare propane next. Here’s the data for propane use at Comp 2:
Propane rate of flow depends on what’s using the propane. We happen to know that the two short-but-broad pulses at 17:00 and 21:30 are domestic hot water; the tall, narrow spike at 20:0 is cooking, and the blip at 19:00 is the water heater maintaining temperature.
Comp 3 also uses propane:
Note that the use pattern is spikier; the peaks are a little higher. It appears that the furnace is cycling two to three times per hour; this is as it should be.
Comparing Buildings: BTU/Sq Ft.
The data is interesting, but we’re really like to compare buildings of different kinds and sizes. To do this, we have to convert the different energy inputs to a common unit — we’ll use BTU, British Thermal Units. But then, since the buildings vary a lot in size, we need to normalize; all other things being equal, a larger building will use more energy than a small one. The Passive House community normalizes based on square feet of living area. Finally, we have to compare energy use over a consistent interval; let’s use a day.
Let’s start with Comp 2, the 1847 farm house. This chart shows BTU/sq ft (the ramp), along with indoor/outdoor temperatures.
This chart sums propane, electricity, and fuel oil to give us the total BTU use, as the purple staircase. The building used about 550 BTU/sq ft on the day measured.
Let’s compare to Comp 4, the offices. In comparison to the old house, the offices are about twice as efficient:
From the picture, you can see that the heat input from oil is relatively constant (unlike the farmhouse, where there’s a staircase effect as the burner cycles). You can also see that electricity is a major energy input — there’s a large server farm in the basement, and the waste heat is partially reused.
What about the 1970 bungalow?
It’s actually just about the same as the office building. This is surprising, as the office building is tighter, has more modern buildings and is better insulated. However, some of the heat from the server room is being dumped out of the building; and the control system for the boiler is probably cycling too rapidly. We plan to study this to see if we can get some savings.
Finally, to give us some perspective, here’s the energy use from a Passive House constructed in 2013. This is an all-electric building. It has no solar hot water, so the energy use shown represents the quality of construction:
Unit 3 is only using 65 BTU/sq ft for this day. This means it’s five times more efficient than either Comp 3 or Comp 4, and more than eight times more efficient than Comp 2!
Here’s what we conclude:
- MCCI’s low-cost metering technology combined with LPWAN radio connections were, as expected, easy to install and trouble free. (We mention this because it still seems remarkable.)
- Comparing buildings based on energy intensity is a great way to discover actionable discrepancies.
- Comparing buildings based on energy intensity is a great way to demonstrate benefits of high performance construction techniques.
- Comparing buildings based on energy intensity is a great way to motivate building owners and maintenance staff to improve building performance, because it shows what’s possible.
- We need a cost-effective way to measure natural gas. Installing propane meters is simple; but due to regulatory issues and cosmetic issues, installing gas meters is not nearly as easy.
Information on the Model 4811 Electric Meter, the Model 4822 Indoor Environmental Sensor and the Model 4832 Outdoor Environmental Sensor can by found by following the links. The Model 4861 Propane Meter and Model 4871 Fuel Oil Meter are not yet on the website but are available by contacting us directly. Our open-source software is on GitHub.
Interested in monitoring building performance using MCCI’s NerveCircuit™ technology? Drop an email to firstname.lastname@example.org, and we’ll set up an introductory discussion.
MCCI has released a new version of our open-source Python API library for RedwoodComm RWC5020B and RWC5020M testers. The MCCI rwc-python-api library, available on GitHub, gives Python programs full access to all the features of the RWC testers, using either serial port or Ethernet connections.
The library supports RedwoodCommm firmware versions v1.150 to v1.305.
Contact MCCI via email for more information.
In a previous post, we discussed MCCI’s USB C® support in TrueTask USB, our embedded USB host and device stacks. This post covers some features of our implementation.
Our Type-C implementation approach emphasizes reliability and robustness.
- We avoid conditional compiles (
#if) in our code. We allow them in our header files to adjust to the target processor using abstract types; and we have certain macros for debugging that expand differently in debug builds than in release builds. But product configuration is generally accomplished at link time rather than at compile time; this greatly reduces the number of separate compiles needed for checking the configuration space, and greatly increases the readability of code by reducing the compile-time configuration parameters.
- We implement our finite state machines as tables of functions, rather than as large switch statements. The Type C Connector specification has seven state diagrams for different kinds of products (Source, Sink, Sink with Accessory, DRP, DRP with Accessory and Try.SRC, DRP with Accessory and Try.SNK, and Charge-Through). Implementing the FSM with a giant
switchstatement would be less typing, but doesn’t allow the compiler to discard unused states unless we use
#if. Using function tables allows different FSMs to share functions as needed.
- We further harden the implementation by representing the allowed transitions in the state tables, rather than embedding them in the code. For clarity, the state functions still request the next state by name; but this state must be one of the transitions allowed in the FSM description; otherwise the Type C FSM goes to error recovery (which puts the Type C port into a safe state).
- We are very careful to keep layers separate. The Type C layer knows nothing about the TCPC; code in that layer can’t include the header files because they’re not in the
#includepath. The TCPC implementation, in turn, is unaware of how registers are accessed at the low level; it uses an asynchronous abstract driver to reach its hardware.
- As mentioned in the previous post, we use a micro virtual-machine to access the TCPC registers. This allows simple register operations to be chained together, with simple logic operations, without the tedious and error-prone process of writing callbacks for each asynchronous register access. Programmer tedium is important to minimize in software of this complexity; otherwise, attention will wander and errors will occur. Writing asynchronous code with lots of callbacks is in any case hard to do, and hard to maintain; it becomes very hard to figure out what is going on.
- We implemented a TCPC register-access log recorder and a careful log display routine, to make it easier to debug problems.
Interested in embedded USB Type C support? Mail us at email@example.com, and our engineers will help you understand all the options.
We’ve recently added complete USB C® port support in the TrueTask® USB / MCCI USB DataPump® portable USB host/device software platform.
Here are some of the key features:
- Explicit finite state machines that are identical to the FSMs in the USB Type C Cable and Connector Specification Revision 2.0. Why? It makes it much easier to debug systems if you can refer back to the canonical specification. Interesting because? Many port controllers, including those based TCPC, incorporate parts of the canonical FSM in their own function. It’s tempting to elide the standard state transitions, but this makes problems much harder to debug, because you can’t refer back to the specification.
- TCPC separated from Type-C FSM. Why? Type C and TCPC are different specs, and keeping them separate makes it easier to correlate code to the relevant spec. Interesting because? The TCPC spec doesn’t really have this concept of separation; see previous point. Further, there’s no requirement to conform to TCPC in implementations; by keeping TCPC separate, we can easily implement drivers for different port-controller models.
- TCPC implementation separated from register access mechanism TCPC can be implemented with direct register accesses or via serial register access busses such as I2C or SPI. This complicates abstraction a lot, if you’re designing a software package to operate in environments from bare iron to sophisticated kernel environments like Windows or Linux. MCCI uses a micro-VM to handle register accesses, which conveniently hides all the details from the TCPC driver.
- Ready for USB Power Delivery. PD depends very much on the Type-C implementation. Our architecture explicitly allows for activating (and deactivating) PD behavior at the appropriate moments in the Type-C FSMs.
Interested in embedded USB Type C support? Mail us at firstname.lastname@example.org, and our engineers will help understand all the options.
MCCI recently has invested a lot of energy supporting the pi64.win project. This project has a simple (and possibly silly-sounding) goal: get “real” Windows 10 running on a Raspberry Pi 3.
Many people have posted about the technical advances that have made this possible. Here’s a partial list.
- The Raspberry Pi 3 supports the 64-bit ARM64 architecture.
- Microsoft ported Windows 10 IoT Core (as a 32-bit operating system) to the Raspberry Pi, but targeted using the system for deploying embedded applications (kiosks, single-function computers). They omitted the features that make Windows 10 desktop a general-purpose system. (MCCI did the USB drivers for that project.)
- Microsoft ported Windows 10 desktop to ARM64 systems. In this port, they included the key low-level drivers, apart from USB, needed for the Raspberry Pi.
- Microsoft open-sourced the key ACPI / UEFI code needed to boot Windows 10 on a 32-bit Raspberry Pi.
- Andrei Warkentin then adapted that and make a real ARM64 UEFI BIOS — this enables booting all kinds of “professional” operating systems on the Pi, not just Windows 10. He also managed to make USB work “well enough” to support keyboard and mouse — kind of important for setting up the BIOS!
- José Manuel Nieto Sánchez organized a group of volunteers, and wrote an tool that would prepare an SD card with the required information from a Windows distribution, available through Windows Insider, MSDN, and other sources for non-commercial use.
- Bas Timmer posted simple drivers that were enough to get Windows through the boot.
- The group convinced Microchip to release ARM64 drivers for the USB Ethernet controller that’s on the Pi 3 mainboard.
- Finally, the group hammered on me until I agreed to take the time to bring up the MCCI host stack (TrueTask USB) on ARM64.
The result was a flurry of world-wide attention. Perhaps predictably, there has been a lot of grumbling about performance. On the other hand, it looks a great demo for MCCI drivers; almost everything tested works. (It’s also a good demo for MCCI’s portability techniques; after four days of wrestling with the build system, the very first build we put on the hardware was the final version, apart from changing the version.)
MCCI has also put a lot of effort into organizing a website (pi64.win) and a discussion site (discourse.pi64.win) for the community, in collecting statistics, running the Twitter feed (@Pi64Win), and helping to publicize the effort.
So, the New York City question is: why do it? What’s your angle?
Of course, there is the basic commercial reason: to demonstrate that our drivers really are industrial strength in 2019. It was a big deal that our drivers were used in Windows 10 IoT Core, but that was a few years ago now. We can now point to a more recent success. In addition, there are a lot of device classes that were impossible to test on Windows 10 Core IoT, because of the difficulties in running regular Windows applications. It’s one thing for a webcam to enumerate; its another for it to actually stream interesting data to the application of your choice. It’s a lot easier to test if you can just spin up a video capture app. We can now point to public results from people testing our work. This is good, and so I thank the group for doing all the work to test and post results.
But there’s another reason, linked to MCCI’s social mission. We want to make a difference to people, not just to our customers.
Right now, cheap computing for people with few economic resources is subsidized (students are a prime example, but just one such group). Things like Chromebooks are subsidized by harvesting data; and they are limited in terms of what they can do (beyond the limitations imposed by their price).
That strikes me as wrong, and as a 19th-century way of solving the problem.
It’s already clear from group experiments that the Pi 3 is not that far away from being able to do significant work with Windows 10. If the group can make something useful to students and people with limited financial resources, it’s not a hobby: it can change lives.
The pi64.win project very likely will not, in itself, put a $35 computer in every student’s backpack (though I wish it would). But it demonstrates what can be done with very low-cost hardware, and it serves as a proof of concept. It may motivate some of the other (larger) members of the ecosystem (Microsoft, the Raspberry Pi Foundation, the Mozilla Foundation) to come together to create a production version.Sometimes a proof of concept is what’s needed to break through inertia and doubt.