One method of measuring current through a wire is using a current sense coil. This is a mostly nonintrusive way of measuring current by detecting the magnetic field around the wire, however it only works for AC signals. In this setup we have a coil of wire wrapped around a ferromagnetic toroid. We then pass our AC current carrying wire through the centre of this toroid and measure the voltage induced on the coil. Due to the very high permeability of the toroid, we can assume that the magnetic field inside it is insensitive to the exact location of the wire passing through the toroid.
I wanted to investigate this relationship between the sensitivity to the location of the wire inside the toroid and the permeability of the toroid. This can inform how high the permeability needs to be before we can assume that the position of the wire is not important. To do this I used the FEMM finite element magnetics package. This allows me to create an arbitrary geometry of coils and toroid and measure the magnetic field inside the toroid.
In the past I’ve used python to create small programs to interface with my hardware projects like EOGee and ShArc. I use the Matplotlib animation class to plot live data, however I’ve found this to be very slow, typically only updating a few times a second. To help remedy this I’ve begun using the Pygame library. Pygame is an open source python library for developing games – it provides a simple structure for running a main loop while drawing to the screen, and update rates of 60Hz are easily achievable.
While using the Pygame library for developing a ShArc demo, I came across a shortcoming in the function for drawing arcs, which I was using the visualise the shape of the sensor.
When drawing an arc of very large radius, I found that the arc typically would not be completely drawn. This is illustrated in the following image which shows four arcs which should be connecting to each other, however clearly there are large gaps between them. If the arc was short enough, with large enough radius, it may not be drawn at all.
As part of my latest EOGee design, I have four devices on a single SPI bus – two 12-bit ADCs and two 12-bit DACs. Each of them is operating at 30kHz, which means that every 33us I have to send or receive 16-bits of data to each of them.
STMicro provide a HAL library which makes sending SPI data really simple using their commands HAL_SPI_Transmit_IT and HAL_SPI_Receive_IT.
So in theory it should be as simple as calling each of these functions four times sequentially, every 33us. With a clock speed of 10MHz, each transaction should take about 1.6us which would easily fit inside the 33us. However it turns out that the HAL library is very inefficient when it comes to small transactions.
For STM32 development I use STM32CubeMX to generate the project and the initialisation code, and then I load it in SW4STM to edit and compile the code. One of the main attractions of STM32CubeMX is that it sets up all the of the dependencies and middleware in your project configuration.
I was modifying my Post-Build steps in Project->Properties->C/C++ Build->Settings when I accidentally deleted all of the entries in my configuration by clicking “Restore Defaults”. This cleared all of my compiler, linker and assembler settings that STM32CubeMX generates.
Last weekend I went to a meetup which was a bit like a hackathon. The title was ‘Multispectral Imaging with Raspberry Pi’. In a lot of ways I am not a fan of the Raspberry Pi – I feel that it was hyped as a great way to get kids into programming, but in reality most kids have access to full Windows PCs which they will be more familiar with and also have much more user friendly programming IDEs, tutorials etc. What interested me was the multispectral imaging, so I went along not sure what to expect.
They introduced the concept of the Normalised Difference Vegetation Index (NDVI). This is a value indicates the health of plant life and calculate by measuring the light reflected by a plant. It is defined as:
Along with USART and SPI, I2C is definitely the most common interface used by a microcontroller to communicate with peripherals. In order to implement an I2C bus all you need is two open-collector collector pins, one for the SCL (clock) line and one for the SDA (data) line. It has to be open-collector because there are times during the protocol when two devices drive the clock line at the same time which can lead to a short circuit if one device drives it high and one drives it low. This way, the bus lines are high by default due to the pull up resistors – if a device wants a line to go low, it just shorts it to ground via an internal transistor. There is no path from VCC to GND that does not contain a high-valued resistor.
A geometric series is a series of numbers where each number in the series is equal to the previous number multiplied by a constant multiplication factor. For example: 2, 4, 6, 8, 16… is a geometric series with a constant multiplication factor of 2.
The sum to infinity of such a sequence, then, can be represented as:
Something that has been annoying me for a while is that there is no way to download your WordPress.com stats from the website!
So I wrote a script in python to allow you to download all of your stats into a spreadsheet. Here is the guide.
Basically, you need to provide the script with an example XML Http Request (XHR) where the website is pulling stats data from the WordPress.com server. From this XHR, the script then reconstructs a new XHR to get all of the data.
Soft switching allows a single button to be used as both an input and a power button. An example of this is the LCR45 LCR meter from Peak Electonic Design which has two buttons – on/menu and enter/off. As you can tell from the names, both buttons operate to turn the device on/off and also trigger the menu and enter functions in the interface.
This could be achieved by using both buttons only as inputs to the processor (a PIC in this case) and never turning the chip off, simply putting it into low power mode and using the ‘on’ button to wake it from this sleep. But even the best low power mode uses more power than actually turning the device off and the battery would eventually drain. So how can we achieve a multipurpose button and still use no power when turned off? To answer this I reverse engineered the LCR45 and drew out the circuit which I will now explain.
Yesterday, I had just got back from campus and was just enjoying a coffee before I got down to work when I got a message from a friend:
“…come and build stuff…”
There was an event on campus called “Make Cool ShMIT – again!”, where they provide a bunch of components and (more importantly) pizza, and you build something in teams for 2 hours. I decided that work could wait and hopped on the bus to campus.