Gas station without pumps

2016 March 31

PteroDAQ bug fixes

Filed under: Circuits course,Data acquisition — gasstationwithoutpumps @ 21:55
Tags: , , ,

I spent much of my lunch break today using a laptop borrowed from a student in the Applied Electronics course to debug a problem in PteroDAQ (one that I thought I had fixed on 2016 Feb 6 and again on 2016 March 30).

The problem was that on newer versions of Mac OS X, our original way for finding the serial ports and listing them in PteroDAQ (with good names) was failing, and the serial ports weren’t appearing. I fixed it for Mac 10.11.3, but that fix was breaking for most of the students in the course.  Yesterday, a student who is a friend of a student in the class suggested that the problem was just that I was only looking for USB 2 ports, and that the new USB stack used different data types for USB 3 ports.

Since I did not have any hardware with USB 3 ports (yes, I hang onto my computers for a while—the machine I’m typing this on is a MacBook Pro bought in mid-2009), I was unable to test the fix, so I released it to the class and asked them to test it.  A few students reported it working, but in the lab this morning, several students with Mac OS X computers were still unable to use PteroDAQ.  It was clearly a USB 2 vs. USB 3 problem still, since they were able to use PteroDAQ if they connected using my cable that has a USB 2 hub in it. One other student had gotten PteroDAQ to work for her by using a USB 2 hub that she had bought just for the purpose (probably a $7 or $8 one from Staples).

So instead of eating my lunch of raw vegetables, I sat with one of the laptops that was failing, uncommented some debug print statements that I had left in the code (I don’t delete debugging statements—I just comment them out, precisely for this sort of later bug fixing), and looked at the data structure for that Mac.  Apparently there are many different USB stacks for Mac OS X, with all sorts of differences. I put together ways of finding the appropriate name for the serial port using as many different methods as I could think of, based on either the child or the parent of the object in the chain that had the name I wanted.

After it was working on his computer, I handed it back to him and redid the bug fixes on my laptop and pushed them back to the bitbucket site, asking students to test the new code.  So far, everyone who has tested it has gotten it working (except for one student who seems to have a fried Teensy LC board—we were not able to get even the Arduino environment on my Mac to see his board). We don’t have any spare Teensy boards, so I suggested he order one from PJRC with the male headers already soldered on.  That makes two students (out of 48) who have had to order replacement boards (the other one soldered the male headers on the wrong side of the board, and delaminated some of the pads in attempting to correct the problem).  Perhaps next year we should order an extra 5% of Teensy LC boards, to cover for this sort of problem and have a local source for replacement boards.

I managed to finally finish my lunch after lab ended (around 5:30pm), but I’m glad to have gotten PteroDAQ working for (almost) everyone.  It is now 10pm, and time for me to prepare for tomorrow’s lecture.

2011 August 14

Pressure sensor

I’ve been thinking about what other parts I need to buy for the high-school Robotics Club, so that they can finish their underwater vehicle.

Some I’ve known about for a while, but just haven’t gotten it together to buy the (expensive parts).  For example, they will need several IP-68 connectors for the tether power, for the tether CAT-5 cable (see Long USB cable problem solved), for the motors, and for whatever suite of tools they build for this year’s challenge.  I bought a 4-pin Buccaneer standard connector (made by Bulgin)  for the power tether, and am leaning toward 8-pin mini Buccaneer connectors for the motor and tools.  I’ve still  not decided whether to get another 8-pin mini Buccaneer for the Ethernet connection, or to try using their IP-68 ethernet connector.

One that I only just started thinking about is a pressure sensor for determining depth. The challenges for the past 2 years have involved going to a particular depth, so having a depth gauge is a good idea.

Pressure sensors are classified into 4 types: differential, absolute, gauge, and sealed gauge.  In truth they are all differential, measuring the difference in pressure.  The absolute gauges measure the difference to a vacuum chamber, the gauge-pressure sensors measure the difference to atmospheric pressure, and the sealed gauge sensors measure the difference to a sealed chamber that has a known pressure in it (probably around one atmosphere).

If the club members put the pressure sensor sticking through the wall of the dry box, we could use any of the types of pressure sensor, but absolute or sealed gauge would be best, since we don’t know how much the pressure inside the drybox changes as we submerge it.  The sidewalls will flex, so the pressure will go up, but we don’t know how much.

I spent some time today looking for pressure sensors at DigiKey. It looks like absolute pressure sensors are cheaper and easier to find than sealed-gauge, so we’ll go with them.  There are also price variations depending on whether the sensor has temperature compensation, and on whether the output is a low-voltage differential signal or an amplified one ready for input to a microprocessor A/D input.  I’m pretty sure that we need the simplest interface we can afford, so the ones that don’t need external amplifiers are the best bet.

I also spent some time reviewing how much pressure to expect at different depths, so that I could help the club select the appropriate part.  I found an on-line pressure calculator that can convert depth of water to pressure (in PSI, kPa, or atmospheres).  Each meter of depth adds 9.8 kPa (or 1.42 psi).  In a 20′-deep pool,  they could have up to 59.7 kPa, and in a 12m deep pool (like at NASA) they could have up to 117.6 kPa.  Of course, this is just the water pressure that is added to the atmospheric pressure, so the real range they need to cover is 100 kPa to 220kPa.

It looks like Freescale Semiconductor makes some absolute pressure sensors with a 20–250 kPa range (for example, the MPXH6250AC6T1), which is just about right for us.  They run on 5 v and provide a ratiometric output, that we should be able to read to 10 bits of precision, or about 0.25 kPa, which would be a depth resolution of 1 inch. The accuracy of the pressure sensors is only ±1.5% of 250kPA, which is ±3.75kPa, ±15in, or ±38cm.   They get full points if they are within 50cm, so this is accurate enough for us.  The could calibrate to higher accuracy, by lowering the machine at the side of a pool while looking at a ruler or tape measure along the side of the pool and taking measurements.  So, now that I know what is needed, I can have the robotics club try to solve the design problems.

I think I will have to do one more thing for them, though—the pressure sensor is a surface-mount component, so I think that they will need a breakout board for it.  I’ll design a breakout board that has room for some bypass capacitors and an output filter capacitor.  Although surface-mount, the part has 0.05″ pitch leads sticking out, and so should be hand solderable, though it might be worthwhile to get a heat gun and solder paste to try reflow soldering.

Come to think of it, since the pressure sensor will be glued to the side of the drybox, it might be a good idea to mount the 3-axis accelerometer on the same board.  That would reduce the amount of cabling they need to do.  But the ADXL335 chip has the SMD pads underneath the chip, which can’t be easily hand-soldered.  That brings up the question of whether we try soldering with a heat gun or toaster oven, or pay $12 more for the chip already on a breakout board. (The DigiKey breakout board is the same price and a similar design to the LadyAda  breakout board—both are copying the ridiculously overpriced breakout board from Analog Devices.)

I could play around with a few different designs and stick them on my next PC board run—I want to do a revised version of the HexMotor board anyway, and it won’t cost any more to toss in some sensor boards on the same fab run.

2011 July 12

Long USB cable problem solved

Filed under: Robotics,Underwater ROV — gasstationwithoutpumps @ 22:07
Tags: , , ,

I posted a couple of days ago about determining that the USB cable-length limit is real, and needing to get a USB-CAT5-USB converter. I found a couple for only $8 (and free shipping) from “bargain cable” sold through Amazon.  I ordered one of each, and they came today (order on Sunday, delivered on Tuesday is pretty good turnaround!).

Although the two parts I ordered had different prices:

HDE USB over Cat5/5e/6 Extension Cable RJ45 Adapter Set    Sold by: bargain cable    $8.60 each
USB over Cat5/5e/6 Extension Cable RJ45 Adapter Set    Sold by: bargain cable    $7.99 each

they were identical.  The prices seem to be different today also, but within a few cents.

There is one minor problem:  there is not a USB type-B connector on the slave end, but a USB female type-A.  This is easily fixed (just plug in a standard USB A-to-B cable), but it does indicate sloppy engineering.

50' CAT5 patch cable

I tried hooking one set up with a 50′ CAT-5 patch cable (under $5 from Parts Express) that we are likely to use as part of the ROVtether. I had no trouble downloading Arduino programs or getting data back at 115200 baud—even powering the Arduino over the cable worked fine. So that seems to be one big problem solved very cheaply! I love it when off-the-shelf cheap parts do exactly what I need.

2011 July 11

Long USB cables

Filed under: Robotics,Underwater ROV — gasstationwithoutpumps @ 01:20
Tags: , , ,

One of my Arduino projects is not really mine: I’m coaching a high-school robotics club that is building an underwater remotely operated vehicle for the MATE contest.

They had barely gotten a vehicle assembled (and not yet tested) for last year’s competition, so they decided to work on it over the summer.  Their goal is to have an Arduino and  motor controller in a dry box on the vehicle, and have digital signals sent to the Arduino over low-power cable, with just one power cable for their 12v motor power.

One of the first concerns I had was communication with the Arduino.  The USB standard limits cable length to 5m, and the tether for the ROV needs to be at least 10 and probably 15m.  (The best explanation of the reason I’ve found is on a USB developers’ FAQ.)  I was hoping we could stretch that a bit, as we do not need high-speed communication.  So today, the students chopped up a cheap USB cable (after first making sure it worked) then soldered in 33 feet of cable in the middle.  We tested the cable for continuity and shorts, and everything looked fine from a DC standpoint.  When we plugged it into the laptop, the Arduino power light lit up and the TX and RX lights blinked in the normal way for startup.  That meant that the laptop was probing the Arduino and it was responding.  Unfortunately, the laptop did not recognize that there was a USB slave device present, probably because the ringing in the long cable was causing too much signal interference (the reason for the cable length limitation).  So it looks like the USB standard really is pretty strict about the cable length, even if you only need low-speed communication.

Since we don’t want to put boosters in the tether every 5m (sealing underwater electronics is a pain), we’re going to need a different method.  The USB developers’ FAQ says:

Q:  I really need to put a USB device more than 30 meters away from my PC. What should I do?

A:   Build a USB bridge that acts as a USB device on one side and has a USB host controller at the other end. Use a long-haul signaling protocol like Ethernet or RS-485 in the middle. Using cables or short-haul fiber, you can get ranges upwards of a kilometer, though there’s no reason why the long-haul link in the middle of the bridge couldn’t be a pair of radio transceivers or satellite modems. Embedded host solutions capable of doing this already exist. Also, two PCs connected via USB Ethernet adapters are essentially a slave/slave version of this master/slave bridge.

The RS-485 or RS-422 standards are simple low-speed connections, and it is easy to get a USB-to-RS-485 or USB-RS-422 converter. The RS-485 is a 3-wire half-duplex system (differential signal and ground), while the RS-422 is a 5-wire, full-duplex system (2 differential pairs and ground). Unfortunately, these are all designed to plug into a computer as the master.  I’ve not found one designed to hook up a USB slave device (like the Arduino) to an RS-485 bus.

Converting to Cat5 cable seems like the more popular choice.  For about $8 I can get a USB-Cat5-USB end-to-end solution that is supposed to work for up to 150 feet.  That looks like it may be my best bet, as I already was planning  for them to use a cheap CAT5 patch cable as the digital part of the tether.  There are a few different converters on the market in the $8 price range (here’s another USB-CAT5-USB adapter pair), and the main limitations seem to be  speed (USB 1.1 speeds only) that they need for the USB slave device to have its own power.  Both of those are fine for this application, so we’ll try them out.

2010 November 13

Why no digital oscilloscope for Macbooks and iPads?

Filed under: Uncategorized — gasstationwithoutpumps @ 00:08
Tags: , , ,

This summer I was playing a little with electronic hardware (something I’ve not done much since I left computer engineering as a field) and was wishing I had an oscilloscope at home.  I don’t want one of the huge old CRT oscilloscopes, like the Heathkit that my brother and I assembled as kids (I don’t remember the model number, but looking in the Heathkit Virtual Museum, I think it was the OM-11).  Neither do I want one of the little pocket oscilloscopes that look like graphing calculators, with the same sort of low-quality screens and fiddly interfaces.

What I’d like is a USB device that handles the analog part of a digital storage scope that plugs into my laptop and uses the laptop for storing, processing, and displaying the signals.  There are dozens of USB oscilloscopes on the market, but so far as I could tell, none of them had software that would run under Mac OS X.  I found this a little surprising, as the Mac OS X machines are much more popular with computer scientists and bioinformaticians than Windows machines are, and I thought that computer engineers would have established a market for USB scopes for Macbooks.  It is true that most of the EE students and faculty I know who would be competent to design the analog electronics for a USB scope do not have the programming ability to design multi-platform software.  I guess that the small companies that sell digital scopes don’t have the resources to hire two engineers (one to design the hardware, another to design the software), and so make do with half-assed designs that only run on one operating system.

I think that there is a market out there for USB scopes that can work with any of the common laptop platforms (Windows, Mac OS X, and Linux).  In fact, an all-software solution that works with several of the existing USB hardware devices would be ideal.  This seems to me like a great project for a computer engineering student who enjoys writing device drivers and working out communications protocols with hardware that was probably designed with no attention at all to the needs of software engineers.

If someone is looking for a hardware project, I think that the iPad looks like a great device to be the screen of an oscilloscope.  This would require a digital storage scope that is not a USB device but uses the weird iPad/iPhone/iPod connector.  It would probably need its own rechargeable battery, as the iPad is not going to provide much power.  I don’t currently own an iPad, and have no plans to get one, but if someone came out with a great oscilloscope based on it, I might get one just for that app.

UPDATE: December 2012

I bought a USB oscilloscope that does work with Mac OS X (the BitScope Pocket Analyzer).  Screenshots and comment at FET threshold tests with Bitscope.

UPDATE: January 2017

I bought a much better USB oscilloscope, the Analog Discovery 2 by Digilent, which works with Mac, Windows, and Linux computers. Both the hardware and the software are much better than the BitScope (which has not improved much in the intervening 4 years). Digilent has an excellent academic discount program also. I have a series of posts using the Analog Discovery 2.

%d bloggers like this: