Category: Arduino

Vape Sensor Plotting

The values calculated here are differences from the average of the first 2o samples. The X axis is time, but it’s not well-specified because I didn’t actually set a regular timer, I just collected samples as fast as possible.

As was predicted in the previous entry, the MQ-135 and MQ-3, both of which can sense alcohol, had the strongest response to vape clouds. These are the ones I’d use for the primary detection if I was building a serious vape detecting product.

The MQ-9 and MQ-8 had similar responses, but not as strong. This is kind of interesting, since they are supposed to be good for butane, propane, LPG, and hydrogen, but maybe they just do a decent job detecting light molecules with carbon in them? The MQ-2 response is interesting, since it’s sold as a LPG, propane, and hydrogen detector, but has a moderate response to vapes too.

The much lower results seems to indicate that vape clouds have no VOCs (CJMCU-1100) and no town gas or LPG (MQ-5, but I didn’t need a sensor to tell me that).

In Which Vapes May Yet Be Sensed

I’m coming to the “being a narc” thing a little late, since everyone is now having a panic about cutting agents in vapes killing people (Body count stands at ~15. The cops killed about 678 people so far this year, so y’know, keep vaping and avoid cops, it’s 45 times safer). At any rate, a school in my area was sold fantastically expensive devices that monitor areas for vaping, and report to the school administration when someone does it. The devices are on a subscription model, so they’re not just expensive once, they stay expensive.

This got me wondering what it actually takes to detect vape… vapor. Vape juice is mostly propylene glycol and glycerine, plus a dab of flavor and possibly nicotine. I have two theories about ways to detect this. One is that there will be some material produced by vaping that is detectable with a gas sensor. The other way is that phat clouds can be picked up by a particulate sensor, and the fact that it picks up smoke too is just fine, since the kids aren’t supposed to be smoking in the bathroom either.

MQ-2Combustable gasses, LPG, propane, hydrogen, probably also methane
MQ-8Just hydrogen
MQ-4Methane and natural gas
MQ-3Alcohol
MQ-6LPG, iso-butane, propane
MQ-5LPG, natural gas, “town gas”
MQ-135Carbon monoxide, carbon dioxide, ammonia, nitrogen oxide, alcohols, “aromatic compounds”, “sulfide”, and smoke
MQ-9Carbon monoxide, LPG
CMJU-1100VOCs, toluene, formaldehyde, benzene, and so on

There’s a lot of overlap in these sensors, as well as a lot of ambiguity in their datasheets. “Sulfide” isn’t a thing without whatever it’s a sulfide of. Hydrogen sulfide is a toxic and terrible-smelling gas. Cadmium sulfide is a bright yellow solid. “Town gas” is typically a mix of carbon monoxide and hydrogen. LPG is also a mix, including propane, butane, and isobutane, so having it in a list with any of those is kind of redundant.

I haven’t tested yet, but I suspect that the sensors most likely to detect sick clouds are the MQ-3, the MQ-135, and maaaaybe the CMJU-1100. The MQ-3 claims to detect alcohol, as in a breathalyzer, but the family of alcohols is actually pretty large. There’s ethyl (drinkin’ alcohol) and isopropyl (cleanin’ alcohol) and methyl (killin’ alcohol), in addition to some stuff people don’t typically think of as alcohols, like the sugar alcohols, which includes glycerine. Since glycerine is in vape juice, perhaps the sensor will detect it.

The actual mechanism of these sensors is interesting. They appear to the circuit as a resistor that changes resistance in the presence of a gas. The resistor is made of tin dioxide, which has a resistance that drops when exposed to the gasses, but it only responds quickly if the device is hot, so there is also a built-in heater for the sensors.

Because the sensors have little heaters in them, A) they smell weird when they power up for the first time and B) they take a while to stabilize. I powered them up and watched them on the Arduino serial plotter until the outputs more or less leveled out. Then I vaped at them.

Pretty much all of the sensors had some sort of response, but the thing that seemed to vary between them was that some responded faster than others. The next step is going to be logging which ones are outputting what, so I can tell which ones had the fast response and which ones had the strongest response.

The sensors also have a slight response when I just blow at them with normal breath (I have a control! I’m a scientist, doin’ a science!). Interestingly, for some of the sensors, the reaction to my normal breath was a deviation downwards/towards a lower value, while the vape reactions was uniformly a deviation upwards/towards a higher value. This suggests that including one of the sensors that indicates vaping by the sign of its change would serve as a check, since only vaping would cause both sensors to go up, and normal breath would cause one to go up and one to go down.

int readings[9] = {0,0,0,0,0,0,0,0,0};
int index = 0;

void setup() {
  Serial.begin(9600);
}

void loop() {
  //Read all the analog inputs from A0-A8 (I think they're consecutive...)
  index = 0;
  for(int ii = A0; ii <= A8; ii++ ){
    readings[index] = analogRead(ii);
    index++;    
  }

  for(int jj = 0; jj < index-1; jj++){
    Serial.print(readings[jj]);
    Serial.print(",");
  }
  Serial.println(readings[index-1]);
}

On Looking into Mouse Sensors

That is to say, the sensors from optical mice, rather than a sensor intended to detect the small rodent.

I have 10 boards from optical mice and three desoldered sensors. Among that bunch there are two common IC packages, a 16-pin staggered DIP (4 units) and an 8-pin staggered DIP (6 units). There is also a 20-pin staggered DIP, and two 12-pin DIP packages.

Most of the chips were made by Agilent, or Avago, a spin-off of Agilent that eventually bought Broadcom and started operating under that name. A couple are from At Lab, or as they style themselves “@lab”.

The chip interfaces are very heterogeneous. Some of them just output PS2 data and clock signals, and so are a very integrated mouse IC. Some of them output quadrature signals for x and y motion.

I had high hopes for using these mouse sensors for a couple of hacks. One of them is that they are essentially optical flow processors, so you can use them to either get velocity based on the observed motion of stationary objects from a moving platform, assuming you know how far away the objects are (and so get odometry for a moving robot by watching the ground roll by). The inverse of that is that you can also get how far away an object is assuming that it is stationary and you know your own speed (for height over ground detection in a drone, for example).

Ultimately, though, I don’t think this stash of ICs is going to do the job I want. What I want is something I can drop into projects I’m working on, and reverse engineering each of these, finding the datasheets for ICs old enough to support PS2 protocol, and so forth, would be its own hassle of a project. USB optical mice are $7 or so, so I can’t really justify the effort to get these working, sort out optics for them, etc.

On top of that, drone optical flow sensors with the optics already sorted are like $10-20, so for that use case, I can just buy the part. For robot odometry, I can use the same part, or put optics on a USB mouse that can actually plug into a recent computer, instead of decoding quadrature or PS2.

It feels kind of weird to pick up one of my old projects that I had been kind of looking forward to, and realize that it’s simply not useful or interesting, but I guess that’s just how it goes. At least I can free up that parts drawer now!

ESP8266, Serial Adapters, and Resets

As detailed in the previous post, I’ve been having some trouble getting the Arduino development environment to automatically reset my ESP8266 board using the DTR and CTS lines of the serial adapter. Part of my problem may still have been the cheap serial adapter, but today I found a new part.

The ESP8266 is extremely sensitive to noise on the CH_PD line, and I was using a 9″ long jumper to connect CH_PD to RTS. I confirmed with my O-scope that RTS was pulsing as it should, but the first pulse threw the ESP8266 into some weird state where it spewed noise on a bunch of pins (GPIO0 seemed to be the worst), and uploading would, naturally, fail.

Switching to 3″ jumpers cleared up the problem and let my Arduino IDE reset the ESP8266 as it should.

I’ve changed the schematic in the Github repo for the project to reflect the new reset wiring, but I still have to add a 5V input connection for charging the battery. Once that’s done, I can design a new PCB.

 

Bah humbug

The V2 toybrain boards have the diagnostic LED on analog input 6, which isn’t able to also act as an IO pin. Other than that, though, they work. This entry is mostly a note to me to fix that if I make another rev of the board.

Flashing bootloaders on an ATMega328 with the internal clock enabled

The V2 Toybrain boards are getting pressed into service for an art project that I’m working on, so I’m trying to get a set of them up and running. I use Linux, so the tools for talking to AVR microcontrollers are the Arduino IDE, and avrdude, which the Arduino IDE uses.

I started today by telling the Arduino IDE that my boards are a Lilypad Arduino with an ATMega328 on them. This isn’t true, but the electrical design of the board is such that this is close enough. I also informed the IDE that I had a USBTiny ICSP programmer. That bit is true. I had high hopes (because I’m lazy, and configuring the IDE is not the problem I’m trying to solve) that this would let me just hit the “burn bootloader” option in the IDE. Such is not the case. I got the error message:

avrdude: Warning: cannot open USB device: Permission denied
Error while burning bootloader.
avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

I’m a normal user, and the permissions on the USB device are not such that mere users can talk to it. I figured I’d double-check by using avrdude as root (so the permissions would be ok). Then I ran into my next problem:

sudo avrdude -p m328p -c usbtiny
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9514
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
         Double check chip, or use -F to override this check.

The version of avrdude I have is 5.11.1, and doesn’t ship with a hardware definition for the ATMega328, just the ATMega328P. The P is for Picopower, and isn’t related to anything I’m doing (it mostly relates to the technology used to make the chip, and some power handling options like brownout detection). To get around this, I opened /etc/avrdude.conf and copied the ATMega328P hardware definition. Then I changed the descriptions and a few of the fuse bytes to match the parts I do have, and saved the file. Now avrdude doesn’t flip out about my chips.

Unfortunately, programming them through the Arduino IDE is still a bad plan, as the configuration for the LilyPad Arduino isn’t close enough to the hardware I’m using. Specifically, the Lilypad/328 configuration sets the lfuse bits to use an external oscillator, and I’m using the internal oscillator. Once the bad fuse settings are burned in, the chip doesn’t communicate unless it has a 8Mhz crystal attached to it. The error message from avrdude is:

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

I added a crystal (temporarily) to the bricked boards so I could reset the fuses, and they worked fine after that. One of them had the chip on 90 degrees from the proper orientation too, and gave the same error as the chips with the bad fuses, so that error can be anything from the wiring being bad to the chip being configured wrong.

To use avrdude as non-root, I put

ATTR{idVendor}=="1781", ATTR{idProduct}=="0c9f", GROUP="dialout", MODE="0666"

in /etc/udev/rules.d/99-usb-tiny-asp.rules and restarted udev. That lets users in the dialout group have appropriate access to the USB port for the programmer.

The commands to burn the fuse and flash the bootloader are:

avrdude -c usbtiny -p m328 -U lfuse:w:0xE2:m -U flash:w:/home/ams/arduino-1.6.0/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex

My current fuses are lfuse:0xe2, hfuse:0xda, efuse:0x05.

Now we’ll see if I can send a program to them…

USB parallel ports under Python on Ubuntu

I have this PCB designed to control four flame effects. Instead of running it on the Arduino, I’m doing an FFT on a laptop and trying to control the solenoid drivers through a USB parallel port adapter on the laptop.

Ubuntu recognizes the USB parallel port adapter, and gives me a port in /dev/usb/lp0. I don’t have permissions to access it, because its user and group are root and lp, and I’m neither of those. The specific error is:

>>> p = parallel.Parallel('/dev/usb/lp0')
Traceback (most recent call last):
  File "", line 1, in
  File "/usr/lib/python2.7/dist-packages/parallel/parallelppdev.py", line 187, in __init__
    self._fd = os.open(self.device, os.O_RDWR)
OSError: [Errno 13] Permission denied: '/dev/usb/lp0'

sudo chmod o+rw /dev/usb/lp0 doesn’t get me any closer, because whatever python-parallel does under the hood is not a legit operation on that dev entry.

>>> p = parallel.Parallel("/dev/usb/lp0")
Traceback (most recent call last):
  File "", line 1, in
  File "/usr/lib/python2.7/dist-packages/parallel/parallelppdev.py", line 189, in __init__
    self.PPEXCL()
  File "/usr/lib/python2.7/dist-packages/parallel/parallelppdev.py", line 241, in PPEXCL
   fcntl.ioctl(self._fd, PPEXCL)
IOError: [Errno 25] Inappropriate ioctl for device

The /dev/usb/lp0 device entry appears to be created by the usblp module. I have a suspicion that what’s going on here is that the device entry created by usblp isn’t claimable the way one created by ppdev would be.

Using rmmod to get rid of usblp doesn’t work, it just gets restarted when I re-insert the USB connector for the adapter. Blacklisting it in /etc/modprobe.d/blacklist.conf just means that the /dev entry doesn’t get created, not that ppdev takes over.

Most reports online also indicate that USB parallel ports don’t really act like parallel ports, but only work for connecting parallel printers. Since I’ve already wasted enough time on this, it’s time to go with plan B. I’m going to fully populate the board, so that it has an Arduino on it, and then interface to that using serial commands and possibly Processing or OpenFrameworks.

A New Contender!

As I mentioned back in this entry, I don’t think the further development of the ToyBrain controller is useful. The main use case is amply solved by the Pololu Baby Orangutan. However, there is a project that I want something similar for, where the Baby Orangutan won’t work.

The idea behind the project is to make cheap swarm robots out of small robot toys, using something like the ToyBrain or Baby Oranguntan, but with wireless. The Moteino has wireless, but no motor drivers. The Baby Orangutan has motor drivers, but no wireless. The solution, then, appears to be to make a motor driver shield for the Moteino or a wireless shield for the Baby Orangutan. Of the two, I’m more inclined to do the motor shield for the Moteino, but I haven’t done any really analysis.

Microcontroller fun

The Arduino has a huge hobbyist-level codebase and lots of libraries for talking to various devices.

The 8051 is a venerable old processor that still gets used in lots of stuff because it’s cheap, and has a low gate count.

It’s probably possible to port a lot of the Arduino stuff (everything that doesn’t use specific on-chip features) to the 8051, thus allowing people to use the software environment they are comfortable with on a new chip. The same is likely true of PICs, and other chips.

The general case, then, is to create a translation system that automates, as much as possible, the process of porting the Arduino libraries and environment from one chip to another. This is, at a high level, possible because anything a computer with a turing-complete instruction set can do, any other computer with a turing-complete instruction set can also do. The hang-up would be on limitations of real hardware (there’s a lot of cool stuff in there, but no infinite data/instruction tape).

Potential ToyBrain Substitutes

The point of the ToyBrain project isn’t really to create the ToyBrain hardware. It’s to allow me to have a module that I can drop into children’s toys to add programability. Building the actual ToyBrain modules kind of got off into the weeds a bit, so I’ve taken a look around to see what the prices are like for modules that do more or less what I want. Here’s a comparison.

The Pololu Baby Orangutan. ($20) The Baby Orangutan has a 20MHz ATmega328P microcontroller (32k ROM/2k RAM) and a dual H-Bridge motor driver that can supply around 1A continuious power per channel.

The Cal-Eng MicroDuino ($25) Uses a 16MHz ATmega328P and a dual H-bridge that can supply 800mA per channel.

The Cal-Eng NanoDuino ($35) Essentially the same hardware as the MicroDuino, but about the same size as a penny.

The TinyCircuits TinyDuno + TinyShield Motor ($20 + $20) ATMega328. The motor shield can drive four motors, but has an upper limit of 500mA without heat-sinking, so it would need either a heat sink or for the driver channels to be paralleled. It also needs an $18 programming shield, but that’s a one-time expense. Measures about an inch square, and can be cut down to be round.

Microduino Studio Microduino ($?) Not available yet. Proposed hardware is in line with the others, but the motor driver, programming board, and CPU are all seperate, so the system cost will likely be around $40-60 per system. The proposed motor driver is the A3906, which is a dual 1A H-bridge.

Femtoduino ($12 + $5) ATMega328P microcontroller, 400mA per channel motor driver board. Cheap and very small (dime-sized), but the motor driver is weak.

Digispark + Motor Shield ($9 + $10) ATTiny85 (8K ROM/512 RAM) with 6 IO lines, 4 of which would be used to drive the 1.2A motor drivers. Smaller than a quarter, and very cheap. This probably does not have sufficent IO for my purposes, and is barely cost-competitive with the Baby Orangutan.

Looking at the available competition, if I want something better than just buying hardware, I have to essentially make the Pololu Baby Orangutan, only smaller, and with a higher output current. If there’s a 2A dual H-bridge motor driver IC available, this might be possible, but it won’t be by continuing the development path that I’m on (with a socketed, replacable motor driver). The STMicroelectronics L620x series bridges look good, but cost $7, so my $20 budget for parts would be half-blown on one IC.

For my projects that would have used the ToyBrains, I’m going to use the Baby Orangutan controllers instead. I may eventually see if I can get a small board together that uses the through-hole motor driver chips, but it’s not going to be a big priority.