Category: Electronics

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!

Further Troubles with TinyRobos

The white version of the TinyRobo board that has the missing ground trace also doesn’t have a proper connection for the pullups on the I2C address lines for the motor drivers. The drivers are still there, and scanning the I2C bus with a Bus Pirate (Amazon) showed me that they were at 0x63 and 0x64 on the I2C bus, rather than where I expected them to be (at 0x66 and 0x68). The difference is consistent with a connection that should have been to Vcc being left open.

I’m not wild about the problem, but it did give me an opportunity to set up and use Pulseview/Sigrok, my cheap clone logic analyzer, and my Bus Pirate, so it’s not a total waste.

For my own future reference, as well as anyone else who’s interested, the way to set up the Bus Pirate on Ubuntu is this:

  1. Plug it into a USB port
  2. Open up a terminal and type screen /dev/buspirate 115200 8N1 , where /dev/buspirate is whatever device your bus pirate ended up on. Mine was /dev/ttyUSB0.
  3. The terminal will go blank. Hit enter, and you should get the “HiZ>” Bus Pirate terminal.

The I2C bus scan is runĀ  by hitting “m” to get the menu, “4” to get I2C mode, “3” to set speed to 100kHz, and then “(1)” to run the scan macro.

The cheapo logic analyzer I got is a USBee & Saleae clone, which I got because I’m bad and should feel bad not rich. It has a switch to determine which device it claims to be. In Saleae mode, Sigrok loads an alternate firmware onto it, so I’m not really sure where that falls in the intellectual property/doing the right thing by small businesses framework, but if you can afford one, get a proper USBee or Saleae. They’re much better built (the Saleae Logics in particular are tanks) and have more and better features.

I’m doing all this stuff in Enschede, at U. Twente. I’ve been hanging out with the people in the HMI group, which “does things with stuff”. They do a lot of work with things like proxemics in interaction, socially aware robots and technology, and so forth. There’s something of a distinction here between technical stuff, which is what I do a lot of, and more abstract work with avatars and such. I’m a better fit with the RaM (Robotics and Mechatronics) group, which builds things like pipe-crawling robots and quadcopters.

Bugs in new boards

I seem to have left a ground connection off the PCB, which causes the 3.3v regulator to not work. I’ve fixed it in the PCB design in the repository, but the DirtyPCBs order link goes to a product that doesn’t work, so I still have to fix that.

Since I’m going to have to do a new version of the PCB anyway, I’ve added a blinky light on one of the IO pins so that I can have an additional channel for debug information.

New Swarm Controllers

I’ve ordered the second version of the swarm control boards. If you want some, you can get them here, but I advise against doing so until after a post shows up here saying either that they work, or that they’re busted.

In the mean time, I’ve been realizing that the boards are good for all sorts of stupid tricks. For instance, you can control people using galvanic vestibular stimulation, which uses 1-1.5mA at pretty low voltages (More academic version, more hacking). Since the swarm control boards already use a 3.7v lithium cell, additional voltage regulation isn’t needed (if anything, they may be too weak), and PWM can be used to control the current. A resistor in series might also be good, in case of… errors.

The same board could also be connected to a door latch, or magnetic strike, which would let a user connect to a web page (the ESP8266 can serve web pages and act as an AP) and put in a password to open the door. Lockitron appears to be making a business out of selling this, but the mechanics are cheaper.

Given that there’s also an I2C bus on the device, IO expanders, sensors, and other goofiness could be added to make wearables that respond to the environment, smart dust sensors, IoT nodes for home automation, scales that tweet about how much you weigh, etc. IoT is the new black! It’s a floor wax! It’s a dessert topping!

 

 

 

A Word of Warning

My PhD work (TinyRobo) uses a USB-Serial converter to talk to the ESP-8266 modules in the tiny robots. Normal FTDI cables have a cable that ends in a 0.1″ 6-pin header with this pinout:

  1. Black – Ground
  2. Brown – CTS
  3. Red – VCC
  4. Orange – TX
  5. Yellow – RX
  6. Green – RTS

It turns out that esptool can manipulate the DTR and RTS lines to reset the chip in bootloader mode, which is great for uploading code to it. It also means I can get away with not having any parts on the TinyRobo boards to handle the reset, which is great because it lets me keep the board small. Unfortunately, the FTDI cable I have doesn’t expose the RTS line, so I got a converter module for cheap off Amazon. The particular module I got is this one:

2016-04-15 14.10.13

I added that red wire and cut a trace so that the pins would be:

  1. DTR
  2. RX
  3. TX
  4. VCC
  5. CTS
  6. Ground

So far, so good, but I can’t upload with it. I threw a scope on the lines, and it looks like instead of swinging from VCC to ground like well-behaved TTL serial lines, they swing from VCC to VCC minus some tiny voltage, less than a volt. Adding pull-downs on the lines doesn’t seem to have helped. It could be that the timing is of, but I suspect that somewhere, some cheapskate saved some fraction of a cent on this board, at the expense of it doing the one thing it was supposed to do (YOU HAD ONE JOB).

Serious MOSFETs

2015-08-26 23.44.43

I’m designing a simple H-bridge for simple but large projects. These are 300A 40V MOSFETS. The board also has a driver for the MOSFETs. I hope to find a driver that uses I2C or some other interface, rather than PWM.

2015-10-12 22.13.25

The board overall is pretty small, but I haven’t figured out a good way to heat sink it. The unpopulated round footprints are for capacitors, and when the caps are installed, they block any easy installation of a heat sink over the MOSFETs. I may design the second iteration of the board around thermal management, and have holes for mounting a commodity CPU heat sink over the FETs.

The current design of the board is available here.

I’ve tested a prototype of the current design, and it does work, but I didn’t stress it very hard.

2015-09-13 17.07.01

Safety third!

Say what you will about globalization and the downfall of the USA, I still like ordering stuff from China. It’s cheap, and it takes so long to get here that I forget I ordered it, so it’s a surprise to me.

Recently, I got a bunch of li-poly battery monitors. These (not surprisingly) monitor li-poly batteries and sound an alarm when the battery voltage gets too low. Overdischarging a li-poly battery can damage the battery fairly quickly, and so may mean you have to buy a new battery. This is far better than overcharging them, which can start a pretty dramatic chemical fire.

The monitors I got are these or something very like them. The ones I have have a button which you can press to set the alarm voltage, with a default of 3.3V/cell.

Like a good hacker, I immediately opened one of them up. It has two ICs, one of which is a Atmel 24C02BN, which is a 2kbit I2C EEPROM. The other is unmarked. I had high hopes that it would be an Atmel part as well, or at least marked, so that I could possibly reflash it with my own firmware.

Having 16 pins counts it out from being any of the ATTiny or ATMega series, as well as any of the 8, 16, or 32-bit PICs. I imagine it’s something like an Elan microcontroller, and probably not super-well documented.

I did also find out that the speakers are simple dumb speakers, not beepers, so the micro generates the audio waveform for them. That means if I want to use the beep as a shut-off signal, I’ll have to do a little filtering, or add a 555 as a pulse stretcher.

Shark Interface Still Not Working

Apparently, having figured out how the Shark joystick sends its information isn’t quite enough to get it working with the motor driver. I wrote software to send the same information that the joystick would usually send, but didn’t get a response. Then I assumed that the way the data lines both go high before serial signalling commences might have been some sort of init signal, so I have an Arduino configured to send the same information, and I still don’t get a response.

It’s entirely possible that I don’t have the bit timing exactly right for the serial link, so I’m now working on bitbanging the serial in a more adaptable way, so I can test different bit lengths.

I’m going to keep plugging away at it for a bit, but I also have a plan B: lobotomize the motor driver. Assuming it uses an ATMega8 like the controller, I can pull the control IC and replace it with one flashed with the Arduino bootloader, and then use rosserial_arduino to control it from ROS. That does mean I’d want to log what the controller does before pulling it, so I have a rough idea what signals go where, but it would vastly simplify controlling the system.