Archives for category: Electronics

The Radxa Rock Pro, running the Linaro (ubuntu) 14.04 Server image, provides access to the serial console. This can be very handy for troubleshooting if the device isn’t connected to a network.

In order to use the SparkFun FTDI Basic USB-to-serial, you’ll need some jumper wires, in addition to the FTDI device.

DO NOT CONNECT the FTDI 3.3V to the Radxa Rock.

Using the jumpers (because the pins are arranged on the SparkFun device in a different order than on the Rock Pro) connect the three as follows:

FTDI Basic      Rock Pro

Gnd                  GND

TXD                  RX

RXI                    TX

You can then use a Linux terminal emulation program, such as minicom. Set the data rate to 115,200, the protocol to 8, None and 1 and disable hardware flow control. You may have to press the Enter key  when you first connect. If you send a BREAK condition, you’ll enter the FIQ debugger mode. Type “console” and you’ll leave the debugger mode.


Recently, I wanted to play with the latest build of MeeGo on my Nokia N900. I also wanted to try it on a PandaBoard borrowed from a friend. To do that, I needed a better (greater capacity and higher write speed) microSD card than any I had in my collection. That need caused me to learn more about microSD memory cards. The results of learning about microSD and the speed classification were somewhat disappointing.

According to this article on Wikipedia, a Class 10 SD device is supposed to provide a minimum of 10 Megabytes per second in sequential write throughput. What I found is that, in reality, SD Class ratings are on a par with the claims of used car sales.

In order to try and objectively establish the actual throughput of various microSD cards, I needed some software tools. I’ve used two so far. ubuntu distributions include the Disk Utility, which will measure disk speeds. I believe the tool will only measure sequential writes, not random writes. It also doesn’t allow for any configuration of the testing characteristics, such as block size or file size or number of testing threads.

I also used the Linux utility fio. This is a much more comprehensive and capable tool, allowing you to configure essentially every aspect of its operation.

Using both of these tools with the first microSD card I bought for this new project, I was sorely disappointed. I bought a new Lexar 8 gigabyte microSDHC Class 10 card. The Class 10 states that the card is supposed to be capable of a minimum of 10 megabytes per second in sequential write throughput. My test results indicated otherwise.

Using both the ubuntu Disk Utility and fio, the best I was able to achieve was less than 3 megabytes for sequential write throughput. Using fio to execute a random write test, I learned that this Lexar card wasn’t capable of even one megabyte per second for a random write.

Now, I’m on the hunt for microSD cards with at least 8 gigabytes capacity, which will give me at least 5 gigabytes of throughput for random writes.

I firmly believe that every job is easier with the proper tool. Often times, when troubleshooting an issue with one of my hobby robotics projects, the proper tool is an oscilloscope. However, my hobbyist budget doesn’t allow for the purchase of a full-feature benchtop digital ‘scope. I also don’t use it often enough to justify spending a lot of money on a ‘scope. Admittedly, I also don’t know enough about all of the intricate details of fully utilizing all of the capabilities of a ‘scope. Therefore, the best solution for me is one of the many brands of inexpensive ‘scopes which rely on a PC (usually a notebook) for the display and the data capture. Through my employer I was able to get my hands on a BitScope. In this article I’d like to describe the ‘scope and my experience with it.

First off, the BitScope is shipped from Australia so they don’t generally show up overnight, just in case you require instant gratification from your electronics purchases. This ‘scope arrived in about a week, none the worse for wear.

The reason I selected this particular ‘scope was, first and foremost, because it’s officially supported in both the Linux and the Windows environments. I’m a Linux user but my employer is an all-Windows shop.

I ordered a model BS325. The back of the unit I received appears in this photo:


This brought me to the first wrinkle. The sticker makes it seem like I received a BS326N. I extracted the board from the metal case (which is very easy to do and a nice part of the design) and looked closely at the board itself.


The board is clearly labeled “BS325N” but the sticker on one of the modules clearly states “BS326N”. At this point I assumed those two model numbers are equivalent.

As I mentioned earlier, this unit only has an Ethernet interface. BitScope also includes a crossover cable, for a direct connection between the ‘scope and my notebook computer. Herein I encountered the next wrinkle.

I attached the crossover cable to the ‘scope and my Windows notebook. The Data LED lit solid but not the Link LED. I moved the cable to my Linux notebook but saw the same behavior. Through some more experimentation, I’ve since determined that the labels on the LEDs are switched: The LED labeled “Data” is actually the “Link” LED. Again, not really a big deal.

The next thing to do was to actually configure and try the software. BitScope includes a CD with the software for Linux, Macintosh and Windows. Seeing this warmed my heart. I installed the software on my Windows notebook and my Linux notebook. Then I attempted to connect the software to the ‘scope. Yes, next wrinkle.

The page in the included paper manual looks like this:


Since I had ordered a BS325N, the board said BS325N and the stickers said BS326N, I assumed I should use the factory IP address for the BS325N. Nope. The IP address actually assigned to the ‘scope was, the one listed for the BS310N. Once again, not a big deal.

I did manage to start the software, connect it to the ‘scope and query the ‘scope. The Windows software identifies the ‘scope as a “BS032600”, by the way. I made a few simple tests and played with the software a bit. I tried the same simple tests on my Linux notebook, but the bitscope-dso software complains and then aborts.

I’m still satisfied with the ‘scope and happy to have it. Obviously, their manufacturing quality control needs some improvement but it’s not keeping me from using the tool. I had also contacted BitScope Technical Support when I was looking at the lack of Link issue. It took them almost two days to respond and I was disappointed to receive the all-too-common Technical Support response. Essentially, I was told “This is almost certainly your problem. Check your firewall and network configuration”. The Technical Support staff apparently either didn’t read my note or doesn’t understand networking issues.

Next, I plan to use the ‘scope to troubleshoot some actual conditions in my lab. I’ll provide some more details on how the device worked for me.

Over the years, I have installed several submerged float switches in the bilge of my boat. They’re supposed to run the bilge pump when the level of water in the bilge exceeds a certain level and then stop the pump after the water level is lower. They usually work well for the first year or two but inevitably fail. Sometimes they fail simply because they’re submerged in water constantly and they had a very small leak. Other times they failed probably because I left them underwater over the winter and they were frozen.

To improve upon this I wanted to switch, pun intended, from a submerged mechanical switch to a solid state, adjustable switch. I wanted to be able to remove as much of the switch from the water, hoping to extend its useful life. Of course there are a few commercial switches available but they’re not always customizable. Also, buying a packaged switch wouldn’t teach me anything about the circuitry required or give me the intimate knowledge on how they work.

Now, giving credit where it’s due, none of the circuits in my implementation are completely my own. I borrowed liberally from others who have gone before me. My design has two components and I used someone else’s circuit designs for both. My “value add” was the combination of the two circuits and the replacement of a fixed resistor with a potentiometer, in order to make the switch adjustable.

Before I dive into the design of the circuits, a bit of background may be useful. The level of water in the bilge of a floating boat is not a stable thing. Most importantly, the level rises and falls, not always predictably. The average level of the water may stay the same over longer periods of time but the water can slosh back and forth. Both of these properties can confuse a simple water level sensing switch.

There is a simple solution to this problem though. If the level of the water is sensed by allowing the water to conduct between two electrical probes, setting the height of those probes above the water is important. In short, the pump must be able to reduce the water level to below the height of the probes. Otherwise, the pump will start as soon as the water level rises to, or sloshes against, the probes. The pump will then run and reduce the water level just enough  to break the circuit between the probes and stop the pump. But then, possibly within a few seconds the water level will rise, or slosh, closing the circuit between the probes and running the pump for a few seconds again. This cycle will likely continue indefinitely.

However, if the probes are well above the lowest possible water level and if the pump can run long enough after the probes are above the water level to reduce the water to that lowest level, then the pump is much less likely to rapidly cycle between off and on. If you’re understandably concerned about the pump stopping when the water is running into the bilge non-stop, have no fear. As long as the probes are submerged, the pump will never stop, at least as long as it has power.

Now we can jump into the actual circuits. The first part is the water level sensor. It’s the simpler of the two circuits but possibly the more important part. I started with a circuit from Gary A. Pizl, described at If you look closely at Gary’s design, he has the switch connected directly to the pump. His design has the problem of continuously cycling on and off as the bilge water sloshes. To improve upon that design I disconnected the circuit from the pump and instead connected the output of the circuit to a timer circuit, described in the next paragraph.

The initial circuit for the timer was taken from John Hewes’s monostable design at . I made a few modifications to it, however. I didn’t need the reset capability, because I could simply cut the power to stop the timer. I also found that it works just fine without pulling pin 4 of the 55 high with the resistor to positive voltage. I didn’t put the small capacitor on pin 5 either. The major change was to the value for resistor R1. Instead of using a fixed resistor, I used a potentiometer. That way I could adjust the length of the timer.

The assembled timer looks like this:

Assembled board

And the complete schematic is: