[Revanth Kailashnath] writes in to tell us about an interesting project he and his team have been working on for their “Real Time Embedded Programming” class at the University of Glasgow. Intended to combat the harsh and dangerous winters in Glasgow, their system uses a Raspberry Pi and a suite of sensors to automatically deploy a brine solution to streets and sidewalks. While the project is still only a proof of concept and hasn’t been deployed, the work the team has done so far runs the gamut from developing their own PCBs to creating a web-based user interface.
The core idea is simple. If the conditions are right for ice to form, spray salt water. Using salt water is a cheap and safe way of clearing and preventing ice as it simply drops the temperature at which water freezes. The end result is that the ice won’t form until it gets down to 10F (-12C) or so. Not a perfect solution, but it can definitely help. Of course, you don’t want to spray people with salt water as they pass by, so there’s a bit more to it than that.
Using the venerable DHT22 sensor the team can get the current temperature and humidity, which allows them to determine when it’s time to start spraying. But to prevent any wet and angry pedestrians, a HC-SR501 PIR motion sensor is used. If the system sees motion it will stop for a while to let the activity quiet down.
Monitoring the sensors and controlling the pump is done by a daemon written in C++, which also logs data to an SQL database, which in turn feeds their PHP web interface. In the video after the break, [Revanth] demonstrates how the system is constantly making decisions based on the input of the various sensors. Environmental data and motion is analysed every few seconds to provide a real-time solution.
The Icoboard is a plug-in for the Raspberry Pi with a Lattice iCE FPGA onboard. Combined with a cheap A/D converter, [OpenTechLab] build a software-defined radio using all open source tools. He found some inexpensive converters that cost about $25 and were fast enough (32 MHz) for the purpose at hand. The boards also had a digital to analog converter and he was able to find the data sheets. You can see a video with the whole project covered, below.
The video, by the way, is pretty extensive (about an hour’s worth) and covers the creation of a PC board to connect from the Icoboard to the converters. There’s also a 3D printed frame, and that’s explained in detail as well.
We recently noticed an open source design for TinyFPGA A-Series boards from [Luke Valenty]. The tiny boards measure 18 mm by 30.5 mm and are breadboard friendly. You can choose a board that holds a Lattice Mach XO2-256 or an XO2-1200, if you need the additional capacity.
The boards have the JTAG interface on the side pins and also on a top header that would be handy to plug in a JTAG dongle for programming. The tiny chips are much easier to work with when they are entombed in a breakout board like this. Bigger boards with LEDs and other I/O devices are good for learning, but they aren’t always good for integrating into a larger project. The TinyFPGA boards would easily work in a device you were prototyping or doing a small production run.
We are used to stories about reverse engineering integrated circuits, in these pages. Some fascinating exposés of classic chips have been produced by people such as the ever-hard-working [Ken Shirriff].
You might think that this practice would be something new, confined only to those interested in the workings of now-obsolete silicon. But the secrets of these chips were closely guarded commercial intelligence back in the day, and there was a small industry of experts whose living came from unlocking them.
Integrated Circuit Engineering Corporation were a Scottsdale, Arizona based company who specialised in semiconductor industry data. They have long since been swallowed up in a series of corporate takeovers, but we have a fascinating window into their activities because their archive is preserved by the Smithsonian Institution. They reverse engineered integrated circuits to produce reports containing detailed information about their mechanical properties as well as their operation, and just such a report is our subject today. Their 1979 examination of the Zilog Z80 CTC (PDF) starts with an examination of the package, in this case the more expensive ceramic variant, then looks in detail at the internal construction of the die itself, and its bonding wires. We are then taken in its typewritten pages through an extensive analysis of the circuitry on the die, with gate-level circuits to explain the operation of each part.
The detail contained in this report is extraordinary, it is clear that a huge amount of work went into its production and it would have been of huge value to certain of Zilog’s customers and competitors. At the time this would have been extremely commercially sensitive information, even if it now seems like a historical curiosity.
The Z80 CTC is a 4-channel counter/timer peripheral chip for the wildly succesful Z80 8-bit microprocessor, in a 28-pin dual-in-line package. We were surprised to find from a quick search that you can still buy this chip from some of the usual suppliers rather than the surplus houses, so it may even still be in production.
I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.
So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.
Not only do I get to watch my mistakes in near real time, I get to make a video about it.
Getting Data Out of a Vehicle
I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).
To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.
At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.
Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.
If you buy a used heat pump that was made in China and try to use it in Northern Europe, there are bound to be issues. If said heat pump ends up encased in a block of ice that renders it ineffective, you’ve got two choices: give up and buy a proper heater, or hack a new ice-busting brain board into the heat pump and get back to life.
[Evalds] chose the latter course, obviously, and in the process he gives us a pretty good look at how heat pumps work and how to overcome their deficiencies. In [Evalds]’ Latvia, winters can be both cold and humid, which can worsen an inherent problem with air-coupled heat pumps: they tend to ice up. As the outside coil is cooled to pick up as much heat as possible from the outside air, water vapor condenses out on the coils and freezes. Most heat pumps account for this by occasionally running in reverse, heating the outdoor coils to clear the ice buildup. [Evalds]’ had nothing more than a simple timer to kick off the defrost cycle, and it wasn’t keeping up with the Latvian winter. An Arduino replaced the OEM controller, and wired up to temperature sensors and an IR sensor that watches for ice buildup on the lower part of the coil, the heat pump is now much better behaved.
Of course it wasn’t as smooth as all that — [Evalds] has some hoops to jump through, including EMI problems and a dodgy Arduino clone. But he stuck with it and brought the heat pump back online, likely at far less expense than HVAC techs would charge for a service call.
Building a software defined radio (SDR) involves many trades offs. But one of the most fundamental is should you use an FPGA or a CPU to do the processing. Of course, if you are piping data to a PC, the answer is probably a CPU. But if you are doing the whole system, it is a vexing choice. The FPGA can handle lots of data all at one time but is somewhat more difficult to develop and modify. CPUs using software are flexible–especially for coding user interfaces, networking connections, and the like) but don’t always have enough horsepower to cope with signal processing tasks (and, yes, it depends on the CPU).
[Eric Brombaugh] sidestepped that trade off. He used a board with both an ARM processor and an ICE FPGA at the heart of his SDR design. He uses three custom boards: one is the CPU/FPGA board, another is a 10-bit converter that can sample at 40 MSPS (sufficient to decode to 20 MHz), and an I2S DAC to produce audio. Each board has its own page linked from the main project.