Deathblades: The Birds and the XBees

I’ve been waiting to use that title for a long time.

Building the ‘blades has been quite an exercise in unfamiliar territory. First, the skates will be using the Maxon DEC modules, which are essentially experimental with respect to the project, me having seen no other vehicles that use them (seriously – all other Google results seem to just be press releases). Having access to the DEC modules was the impetus behind me finally learning PCB design and layout.  I just discovered the magic that is force-sensing resistors and how they can be used as an analog throttle.

And now, as the final and pivotal step in closing the proverbial control loop of the Deathblades, I shall link the throttle with the DECs using XBee radio modules.

SOOOOOO CUUUUUUUUTE. It’s just like a really obese centipede with a silly hat! That transmits and receives data!

These little 2.4GHz, 802.15.4 radio modules are very popular in the DIY and maker crowd because of their level of flexibility. They can form star, mesh, and mixed topology networks, and can act as wireless serial bridges. But much of their popularity (at least of the Series 1, not so much the newer models which adhere more closely to the standard) is the ability to act as an airwire. The XBee can be configured to pass two analog signals in the form of 0-100% digital PWM, and then up to 6 more digital I/Os, all without involving another microcontroller in the loop. To make my life even easier, Digi International provides X-CTU,a useful GUI tool for configuring the radios to do your bidding.

I yoinked two Xbee Adapter boards from MITERS’ neighboring student activities so I could easily throw together a breadboard assembly.  Each unit here is receiving 3.3 volts from the FSR board regulator. I set them up such that the transmitting unit receives the analog FSR voltage on AD0/DIO0 and an “enable” signal, on AD1/DIO1.

On the receiving side, the radio has PWM0/RSSI hooked to the oscilloscope, along with its own AD1/DIO1. Digital I/Os are paired, but the analog ones have their own pins.

Conveniently enough, RSSI was connected to a red LED on the boards.

Configuring the radios to act as analog and digital airwires. There are relatively few settings to change, and most of them revolve around how to use the I/O pins. I referenced Rob Faludi’s XBee I/O page (props for being the number 1 Google hit for the exact words “Xbee Direct I/O”) and Digi’s own knowledge base page on the matter. Needless to say, RTFM came in handy also.

The things I changed from the default firmware settings for the transmitting side, all values in hex:

  • Pan ID (ATID)  = 9000, because… well, I could.
  • Radio ID (ATMY) = 1, just a number again.
  • Destination Address L (ATDL) = FFFF, which is the broadcast setting for the simpler 16 bit addressing mode. If I wanted the transmitter to only talk to one other radio, this would be the ATMY of the other radio. But I ultimately want to control 2 other modules, and simple I/O mode doesn’t allow changing of the address on the fly, so broadcast will have to do. Fortunately, there are settings for which radio IDs you should listen to.
  • Digital I/O 0 (ATD0) = 2, for this pin’s ADC mode, hooked to the 0-3.3v output.
  • Digital I/O 1 (ATD1) = 3, for this pin’s function as a digital input, mapped to DIO1 on the other modules trained to it.
  • I left ATIU off because I didn’t need the packet information from the radio’s serial ports.
  • Number of samples before transmission (ATIT) = 1. I don’t know what the effect of changing this to a higher value does – perhaps to filter out noise or slow the rate of updates, but I decided to just transmit everything.
  • Sampling rate (ATIR) = 1. The sampling rate can increment in 1ms resolutions. I decided that 1ms was fine.
  • Input address (ATIA) = FF. This is the which radio is commanding my I/O lines option. In the case of the Tx, I set this to 0xFF, which is the “nobody” option, because… well, this is the transmitter. The receiver would have this set to 1, the ATMY of the transmitter. This was crucial. I missed it the first time and the bridge most definitely did not work.
  • PWM0/RSSI pin mode (ATP0) = 0. The transmitter won’t be putting out a PWM signal, so there is no need to set the pin.

From this, it seems that ATIA = FFFF and ATDL = FFFF will cause all radios to affect all other radios. I’m sure this is not actually the case, because that sounds like a nightmarish scenario.

Next, I set complementary values for the receiving side:

  • PAN ID = 9000
  • ATMY = 2 , this was arbitrarily the 2nd radio in my little network. It could have been the 987th.
  • ATDL = 1, because it should talk only to the transmitter, not broadcast.
  • ATD0 = 0, or disabled, since I’m not using DIO0 as a digital I/O.
  • ATD1 = 4, for this pin’s digital output mode with a default setting of LOW. Logical low disables the DEC’s outputs, which I want. DIO1 is hooked to the enable signal on the FSR board.
  • No ATIU, ATIT, or ATIR (left unchanged or default values)
  • ATIA = 1. This trains the receiver to radio ID #1, which is my transmitter.
  • And finally, ATP0 = 2, to couple it to the analog-to-digital coversion of DIO0 on the transmitter side.
  • I set pin timeouts (ATT0 and ATPT) to 500ms so all the outputs return to their default states if no valid updates are received within that timeframe.

What does all this result in?

Well, first, nothing if I don’t hook up the VREF pin on the transmitting XBee. Which I didn’t. Comparing 3.3v to #NaN always results in bullshit.

But here’s a video of the wireless signal transmission working. The RSSI LED is being used as the PWM output here, and its brightness varies as I push down on the FSR.

The scope clearly shows the 16kHz square wave coming out of PWM0 as well as the changing state of DIO1. On the FSR board, I made an (adjustable) comparator input that drives DIO1 high only after the FSR voltage exceeds a threshold. In the video, it’s about 30%. This acts as a very (very) rough control deadband so random hand flicks don’t cause the motors to turn on.

The downside is that the minimum throttle at activation is 30%. Clearly, this will be adjusted to taste. More sophisticated glue circuitry will better approximate a deadband curve, but this is enough to prove the concept.

One catch: the DEC modules run 5 volt logic but the XBee runs on 3.3 volts! So I lied – even at full throttle, it means a direct signal would only have me crusing at around 66%.

Lame. So to validate one of the experimental parts of the “Double DEC’er” board, I made a small buffer that outputs 5 volts. Two 2n7000 signal FETs are wired sequentially in common-source mode, which makes sure the signal is still rectified. The 5v, 16kHz output is trivially filtered back to a smooth analog voltage by a 1Kohm + 1uF RC filter.

The actual DD board uses SOT parts for smallness.

But did my crazy broadcast plan actually work?!

I set up a 3rd XBee  (had to hunt down a 3rd explorer board for this one…)  in the same fashion as radio #2, except with ATMY = 3.

The presence of a variable red light on both modules indicates to me that they are linked successfully. Probing DIO1 on radio 3 results in the same enable line toggling.

So to wrap up the whole deal with PAN ID, broadcast, radio ID, and destination address (for my own future reference and sanity, as it took me forever to distinguish between them…).

  • An XBee with ATMY x and ATDL y will talk to an XBee with ATMY y and ATDL x if they are on the same PAN ID z.
  • An XBee with ATMY x and ATDL FFFF will talk to any other XBee on the same PAN ID z. But the others will only talk back if their ATDLs are set to x. The others may still converse amongst themselves if their ATDLs and ATMYs are appropriately set.
  • Changing the PAN ID effectively creates another network, and there can be more XBees with ATMY’s x and y which will in turn only talk to eachother.
  • Changing the active channel will create the above scenario all over again.
  • A billion fucking XBees can therefore be in the same general vicinity and will probably still all work.

I hope this is all correct. If it’s not, CORRECT ME. Otherwise I might go through life spreading the same lies and misinformation that I believe in, which puts me awfully close to being a politician.

Time left until Otakon: A month and a week. I think I can bang up a decent cosplay by then.

waiting on you, advanced circuits

Deathblades: Next-day Shipping Edition

I was able to hop onto a lab parts order early yesterday and throw in some force sensitive resistors and prototyping miscellanea. Thanks to the miracle that is modern supply chains and logistics, I had them on my desk in less than 24 hours.

Now, if only Advanced Circuits could finish my Double DEC’er boards that fast. I mean, without costing a significant percentage of my undergraduate tuition.

Oh, speaking of the Double DECers, here’s the latest board iteration featuring discrete 3.3v and 5v regulators. The amount of power I wanted to draw from the 5v line was cresting the limit of the DECs’ onboard regulators, so I added one that runs directly off the battery input. Also, a power LED.

I figured it was safe to stop there for now.

And here’s (part of) the controller parts roster. On the left is a Lilypad Xbee holder and prototyping antiperfboard. Lilypads were designed to be used with wearable electronics, and I figured that the controller qualified as a piece of wearable electronics. These things are actually huge. They looked tiny and cute in the pictures, but are actually about 2 inches in diameter. I foresee no fitting problems, however.

I got four coin cell holders. The controller power will, for now, come from 2 CR2032s in series for a 6 volt power source, which will be regulated to 3.3 volts.

The XBee 2mm headers are for the Double DECers, so I don’t have to solder my poor XBees to the board.

Anyways, here’s How Shit Go Down™ with the FSRs.

Their resistance decays as 1/R with linearly increasing pressure. There is a very high (megohms) unloaded state, and a minimum force must be applied to enter the hyperbolic region. After a certain pressure is applied, the decay saturates at a steady value until you compress it out of existence. Actually, all this is in the datasheet. Why am I explaining it?

I elected to begin experimenting with the “buffered voltage divider” on p. 16. As fig. 9 illustrates, the voltage response is highly nonlinear near zero force. However, with a low load resistance (Rm), the logarithmic curve is approximately linear at higher forces.  And with a high parallel resistance inserted across the FSR, the Precipitous Voltage Cliff is smoothed out to a zero force intercept with a value of approximately (Rm /  Rparallel + Rm) * Vref.

I exaggerated this approximately linear curve even further by using a 1Kohm load resistor, which seems to put me on the edge of the FSR’s 1ma per cm² current tolerance. Next, I set up the op amp buffer as an adjustable noninverting amplifier (as seen in figure 10). Tuning the blue potentiometer effectively let me set the force slope.

Now I had a response that was kinda-sorta-not-really-but-close-enough linear within an adjustable force range. To supplement, I put a slow RC filter (t ~ 0.5 sec) on the output of the amplifier.

After having enough fun playing Squeeze the Resistor, I began to attach it to spots on the wrist plate for ergonomics testing.  The results:

  • Palm area: Good wrist bend force response, but had the unfortunate side effect of also responding when I opened my palm all the way. This was due to the way the sensor was oriented – a normal force could come from either forcing the hand down through the wrist or pushing the palm out by uncurling the fingers.
  • Other side of same area: Very little response at all, because the force didn’t really go that way.
  • Behind the wrist on the flat portion of the plate. This is the 1st class lever equivalent of the first configuration, so it suffered from the same undesirable side effect. Pushing out with the palm also meant that this area of the plate was pushed upwards (with the main wrist strap as a fulcrum), triggering the sensor. Clearly, any response having to do with “opening of the hands” is bad, because that means if I’m trying to recover from an impending faceplant, it will just faceplant me harder.
  • Right under the wrist: Now this was actually promising. While the motion is reverse (i.e. now I pull up with my wrist), the side effect was eliminated – if not, it was a transient at most.

Crap, should have made the damn wire longer.

And so I actually settled with the original motion I was going to reserve for a brake or reverse mode. Now, something that can clearly solve this issue is having multiple FSRs such that different ones are triggered depending on hand position. The ability to distinguish between the open hand and limp hand with wrist pressure positions clearly mean the difference between go faster and oh shhhhh–.

However, that would require some software processing of the multiple signals, and I want to just start simple for now.

Here’s a short video illustrating wrist bend control. In the video, the control looks sensitive with respect to distance displaced, but that distance comes with substantial force applied against the wrist straps and plates. It’s actually quite easy to maintain a certain voltage position, and the “muscle twitch” response is well damped due to the filter.

The moving line scale is 1 volt per division, and the maximum output voltage is just under 3.2 volts. The system runs on a 3.3 volt bus (XBee native voltage) using the LMC6484 rail to rail I/O op-amp to take maximum advantage of the low voltage swings.

Next mission: Transmit this 0-3.3v signal to another board using the XBees in direct I/O bridge mode and decode & buffer the output to 0-5v.

Read more “Deathblades: Next-day Shipping Edition”