Archive for June, 2010


Deathblades/RazErBlades: Race to the Finish, Part 2

Jun 26, 2010 in Project Build Reports, RazErBlades

Time for Version 2.0…

After falling over for about 10 hours, I returned to MITERS to tackle the last Double DEC’er board and the left skate. I had a few track notes in my head left over from the assembly of Deathblade-R that facilitated faster assembly of Deathblade-L.

I originally was going to put together the experimental Double DEC’er along with two “permanent” ones. Since I didn’t find that necessary any more, only one of the boards will be built out. This time, I started with SMT parts first, then moved onto the headers and through-hole parts. Sidebullets and trace reinforcement were also added while the board was unmounted.

I also stripped the other battery pack and built the power switch harness beforehand, so everything just dropped in.

The batteries are retained by gravity, and the DEC boards simply drop on top of them and seat with double sided tape.

And Deathblade-L is (mostly) complete. The motors have no connections yet because I’ll eventually have to take them apart to glue the magnets in. I decided to save on that assembly step for now.


Deathblades: Race to the Finish, Part 1

Jun 26, 2010 in Project Build Reports, RazErBlades

First off, I would like to thank Adafruit Industries for graciously donating a small flock of XBee radios and breakout boards. I can now start an XBee farm and isolate true-breeding strains of particular mutations.

Go buy stuff from them because they’re awesome!!

Over the past roughly 2 days, I blitzed through the Double DEC’er boards and put both units together (with the left side still without magnets, so it just freewheels). I’m proud to say that I have successfully test piloted the ‘blades and am not currently suffering from severe cranial trauma. They’re actually quite tame, but there is plenty of room to tune and refine.

Here’s the rundown.

I got all the special and SMT parts I needed from Digikey in massive quantities because the rest of MITERS could also use them. This build would also be my first foray into using surface mount parts of any type. Before now, I couldn’t see SMT parts out of principle, but I think my vision is slowly getting sharper. 1206 components now register as one pixel.

A preliminary height check using only the tallest components shows that the board would need significant compactification in the vertical dimension if I was going to actually fit them into the frames.

I briefly considered soldering the DECs directly to the boards, but elected to go ahead and make one board that had every expensive component (read: XBee and DECs) be removable and see if I could make that fit. If the tallest board does, then any other possible layout would also fit.

oh god surface mount fffffffff

It wasn’t that bad at all, actually. At least not with SOT223s and 1206 packages, which, for surface mount, are comparatively huge. A very, very clean soldering iron tip helps immensely. Up until this point, I was used to flying with completely grunged tips.

Tweezers are also handy.

All the discrete components are loaded and the board passes its power-on check! 5 volts and 3.3 volts all appear at the correct places.

I noticed the 5 volt regulator heating up quickly when an Xbee was loaded into its socket. This is due to it having to drop 24 volts (or thereabouts) to 5, all while flowing 50 to 60 milliamps. The 5v linear regulator itself was a last minute addendum to the schematic because I thought the DECs’ onboard 5 volt supplies (rated at a paltry 35 milliamps each) could not hold up the XBee and the motor sensors alone.

However, with both DECs in, it appears to be fine. Anyone know what the hell actually happens when you have 2 switching and one linear regulator all paralleled?!

Here’s the hookup for a bench test with one motor. In a serendipitous discovery, the 2.3mm male bullet connectors slip right into the motor phase output connections for convenient testing.

Maybe a two motor test is actually better…

Here’s the test video of what essentially amounts to a full Deathblade power unit, just strewn out on the table. I moved over to a location with a bigger power supply for this test because the MITERSupply was current limiting too hard, but I lacked the confidence to throw it on the full 6S lithium pack.

A closer view of a finished Double DEC’er board.

Alright, so here are the problems. The board in the “100% reversibly assembled” configuration doesn’t actually fit within the confines of the skate frame if the battery pack lies vertically. Additionally, the battery turned out to be several millimeters wider than its specification, which meant that it could not lie horizontally without either modification or severe machining of the frames.

The root problem, of course, was the battery. I ended up taking both ways out.

Step 1, the meche way out.

Using my longest 3/4″ roughing endmill, I thinned down the walls of each frame about 1 millimeter each. This operation turned out to be painless because of the ridged cutter surface (one of the advantages of roughing mills). I had otherwise expected such a long depth to chatter uncontrollably.

As long as I had Lady Bridgeport warmed up, I bored a power switch hole in the side of each frame. While I normally just disconnect the battery for most of my creations (even RazEr), I thought it would be more slick to have an Epic Switch on these.

The aforementioned Epic Switch. I found two of these haunting the Media Lab, and they were the only square switches I located which did not also require a square hole (harder to drill, you know).

I wouldn’t have minded (mound?) a round switch, but couldn’t locate two matching ones.

Hey, the battery now fits in!

Kind of. The main power leads exit out the side of the back, and they are very securely soldered…

To accommodate these, I’d have to slot out a section of the frame. This would horribly compromise the structural integrity, unfortunately.

So this calls for step 2: the EE way. I’ve moved wires on batteries before, so I didn’t hesitate to rip apart the pack to investigate that possibility here.

For what it’s worth, once the shrinkwrap comes off (it’s thin and nonstructural), the batter actually fits completely into the back of the slot where the endmill couldn’t reach.

Hey Hobbyking, do I still have a warranty on this thing since I didn’t violate the sticker? :>

Tearing deeper into the pack (yup, warranty is definitely gone…) reveals the power and balancer connections. The packs are very well made and all connections are on PCBs. Many early lithium polymer packs had direct-soldered leads.

Well, that was simple. A giant soldering iron and some leaded solder later, the wires point into another axis.

Of course, these two joints are now metallurgically indeterminate. The packs are made with non-leaded solder, but Lead-Free is for Losers™… and I only had normal solder anyway, so some of it got mixed into the glob.

I wouldn’t send it into space, but for now, I think it’s fine…

While I had the soldering iron heated and the battery’s wire leads detached, I changed the XT60 bullet connectors to some Deans connectors in order to standardize my battery packs. Who knows – eventually, they might be part of a Super Deansbus.

A spur of the moment rummage through one of our many capacitor bins unearthed some 470uF, 50 volt capacitors that were narrower in diameter than the buscaps I ordered. In fact, they fit exactly into the dead space that the DEC modules overhang!

The response was obvious. I knocked about 3mm of height off the board and gained some capacitance!

After all the modifications, I’m still almost stepping on the XBee. There’s maybe 2 or 3mm of normal distance between its edge and the nearest boot surface.

I’m not concerned, however. Even if I weigh enough to deform the boot, the whole Double DEC’er board is mounted on double sided, cushy foam tape, good for another millimeter.

I discovered that the mating bullet connectors solder very well to the original output connection pads. So, side-bullets it is. It saves even more vertical space, but I still think a short section of wire pigtail with these on the end would have been better. The bullet connectors require alot of “engagement length”, which was difficult to provide in the space behind the battery.

The Epic Switch was rotated to a vertical orientation for better wire exit points. I’ve also added connectors to the DEC’er boards themselves so they may be readily removed.

And the other motor is mounted…

I had a bit of fun determining the proper orientation of the motor vs. its rotational direction vs. the configuration of its 3 phase inputs, which took about half an hour of guess-check-forget-and-guess-again.  Then I dropped the boot on for good. With Loctite!

This is it. This is Deathblade-R, fully completed. No more mods are necessary, nor parts missing. If I wanted to, I could one-leg-skate my way around. Except I don’t actually know how to do that, so I’ll save the potential for broken limbs and knocked out teeth.

I’m going to go ahead and put together Deathblade-L anyway, but the motors do not yet have their magnets. The order’s been placed, but it could be three weeks (!) or more before they arrive.

The battery connector hangs out the side for easy access when I need to charge them up. I could have taken it one more step and put together a charging port, but I felt that was superfluous for the first revision.

By this time, the garbage trucks were rolling in to empty the dumpsters and facilities personnel were poking their heads in the door wondering who the hell was up this early, so I put Deathblade-R on the charger and called it a night…


Deathblades: Skatroller

Jun 24, 2010 in Project Build Reports, RazErBlades

That’s it – I’ve cast the die, thrown down the gauntlet, brought the house, and so on. I’ve registered for Otakon, which, besides being a peer cloud adventure, will be a thinly cosplay-veiled ground test for the Deathblades.

That means I actually have to finish and get moderately proficient at the delicate exercise of not getting skullfucked by the ground. Fortunately for me, Advanced Circuits did finally come through:

Check it out – it’s the updated Double DEC’er boards in AC’s nude color scheme. I elected to use their “Bare Bones” service because it doesn’t take very long. From the time I ordered (last Friday) to when I got them (today, Wednesday) was less than the time it took to get the SCHBs printed.

You know what – I don’t care if they have neither solder mask nor silkscreening. They’re conductive in the right places and insulative in the other. I can live with that… or give them a snazzy color scheme myself.

Unfortunately, when I said “waiting on you, Advanced Circuits” last time I actually meant “waiting on you, Digikey”. All the SMT and special parts needed to fill the Double DEC’er boards are in hyperspace at the moment, but they should rematerialize soon.

Here’s the consequence of designing in the lithium battery packs and then finding out they only fit in the “tall” configuration. I’ll be practically stepping on the Xbee the way things are turning out – and this isn’t even with the DECs in headers. They will have to be permanently attached to the carrier boards. Only a real fit will tell whether or not I’m truly space constrained.

In the worst case, I’ll make some spacer plates for the boot to be mounted a few millimeters higher.

Meanwhile, as I await the LAST PARTS SHIPMENT!!!!!!!!!, I will de-breadboard the hand controller and mount it to the wristpads. Here’s the fun part for today:

We begin with a Lilypad protoboard.

While I could have used any random-ass protoboard, the Lilypad boards just looked more elegant. Nothing will look in place zip tied to a skating accessory, so it might as well be cute, right?!

On the board I have already mounted a 14 pin socket for my favorite op-amp, the LMC6484.  Additionally, I’ve already set up the resistor divider and a connector to attach the FSR in the glove.

this is where it stopped being cute.

The Lilypads are “anti-perfboards”, which mean all the holes are connected together by a tiny trace which you can selectively cut to create conductive paths.

this is quite possibly the worst idea ever

The problem is that if your circuit is even moderately complicated, it takes forever to remember which little traces you forgot to cut or which traces, Robot Jesus forbid, shouldn’t be cut

it is much slower than point-to-point’ing with kynar wire or just bending component leads into eachother

After trace-snipping (which is not easy, I assure you, because it essentially involves digging up the fiberglass substrate) the op amp socket and the resistor divider, I had enough.

what the hell i dont even

I took the dullest razor blade we  had and, over the course of half an hour, scraped up every single trace in a grid pattern, leaving me with a normal perfboard and possibly contributing more to developing carpal tunnel syndrome than 3.5 years of build report typing ever did.

Then I continued.

“Rename N-dollar-sign-1 to ground? Of course.”

See, this is how I roll. Cranking the soldering iron to 850 degrees, its maximum, lets the tip melt instantly and cleanly through 30 gauge Kynar insulated wire-wrapping wire (which does not burn or smoke). It makes a quick and clean joint wherever I need it. Borrowing the concept of nets and buses from Eagle, I just connect one wire point-to-point-to-point before cutting off at the end.

Here’s the part where I have a brilliantly horrible plan and go nuts with it. I cut up a set of wire-wrapping sockets and used the legs as conductive spacers between the XBee Lilypad and the protoboard. The socket legs fit snugly into the Lilypad’s external connection holes.

The XBee’s 3.3 volt, ground, D0, D1, and V+ pads are all soldered to the protoboard’s pads below. One additional pad (“NC”) was secured just for more structure.

The result? A small, adorable Lilypad stack with the XBee on top and the glue circuitry on the bottom.

I couldn’t refuse the temptation of adding a power status LED in bright nuclear reactor meltdown blue. Hello, my name is excessive power consumption.

The XBee Lilypad’s onboard 3.3v regulator supplies power to all the logic.

Here’s the 100th build picture of the Deathbldes. Unfortunately not very dramatic. After verifying that the circuit still worked, I drenched the backside in Automotive Goop for insulation.

Goop is one of my most favorite adhesives because it’s rubbery and flexible (yet stiff in thin coverage),  dries and sets fast, and bonds everything.

After a few minutes, I remembered that Goop was in fact a glue and, thinking fast, shoved a piece of hook-side Velcro onto the Lilystack.

The entire top side of the wristpad is covered in fuzz-side Velcro, so this facilitates mounting without resorting to something more permanent, like sewing (AAAAAAAAHHHHHHH)

The battery holder got much the same treatment. Two CR2032 lithium coin cell holders are Goop’d onto a small piece of scrap aluminum. Another chunk of Velcro is attached to its back.

The system will run on 6 volts. This is subject to change, since this may be more drop and power dissipation than the very small regulator on the Lilypad can handle. I may change to a single high-capacity lithium polymer cell.

Here’s how the whole thing goes together!

Notice the other LED I’ve added to the top board. It’s connected to the ASC (associate) pin of the Xbee, so it blinks annoyingly and brightly if the XBee is powered and active.

From the side.

The two trimpots set the force response slope of the FSRs and the “enable threshold”.  It turns out that 25 to 20% is a better threshold than the 30% tested previously. I highly doubt the skatemotors will even produce enough torque to matter at 25% throttle anyway.

and it glows

That’s the important part. Green ASC blinkenlicht, and a blue steady power light.

Trying out a different configuration now. This is where having a huge Velcro surface comes in handy.

And a third. This one keeps the electronics out of the way of the wrist straps so I don’t have to remove all the electronics first before taking the wristpad off.

I’m very satisfied with how Skatroller turned out. The only problem turned out to indeed be power consumption. The two bright LEDs run straight off 3.3 volts, along with the XBee’s relatively strong hunger for power, meant the poor CR2032s went flat within 10 minutes.


So expect the ASC light (at the minimum) to come off and the blue power light to get a resistor. Additionally, I’ll probably take myself up on the single cell lipo challenge. Three AA cells at 4.5 volts would make a good high capacity power source, but that’s extremely bulky.

Can XBees take a straight single cell Lipo (3.0 to 4.2 volts) without death?! Perhaps an A123 cell (2.7 to 3.6v)…  I mean,we totally don’t have any of those lying around at all.

digikey where are you

More P-P-P-Power than your Arduino has room for

Jun 23, 2010 in Project Build Reports, Reference Posts, Stuff

Have you ever felt the urge to control multi-horsepower electric motors?

with an arduino?

Doesn’t quite work like that…

A few months ago, I did. During that time, Super LOLrioKart and the mini-CityCar were both looking for a compact 36 to 48 volt, 1-brushless-and-1-dc motor control solution of roughly the same power requirements. The attentive reader (all -2 of you) would notice that a few months ago, I didn’t yet possess the skills to design printed circuit boards, and I would be hard pressed to make a good power converter on the back of an Arduino protoshield, or a chunk of perfboard.

Actually, I’ve tried before, and it failed miserably.

But the cool thing about the MITERS clique is that there is alot of cross collaboration. Being mechanical engineers, Shane Colton and I naturally build electronics, power converters, and motor controllers (because those are totally things that mechanical engineers do). And so, at my constant (b)egging, he created the Hexbridge shield, and then refined it to version 2, which is more compact and… more functional.

And now, the (impending) torch has been passed to me. So my goal is to make this thing run a standard sensored brushless DC motor, kind of like a more elegant FVM. It would be the first time I code up a BLDC controller of any kind, Arduino or otherwise, and is the logical step after creating the Kartroller’s H-bridge drive.

The rundown on the Hexbridge shield (/Hexshield): 12-48 volts (nominal) operating range. 30 amps or so continuous operation, more (50-60+) with special attention and addons such as trace reinforcement. Six half-bridges grouped into two gangs of three, i.e. enough to make two BLDC motor controllers. The two gangs each operate off 1 Arduino PWM pin (namely, D9 and D10). The FETs are D2PAK IRFB3207 units, good to several quintillion amps and according to folklore, will desolder themselves long before burning up due to heat!

Because you the user programs the Arduino part, it really can be anything.

As noted, more shields can fit on top of the Hexbridge.

In this case, I’ve put together the Arduino WireBrushLess Tower, the future wireless brushless DC motor controller. The XBee radio module takes commands over the air and the Arduino can read them via its serial port. The idea is to have all of these controllable from a command console in order to make vehicles that go whichever direction you feel like without worrying about tangling control cables.

The small protoboard area next to the Xbee acts as a convenient signal interface stage. The long header presents 3 Hall Effect sensor inputs, logic power, and ground.

For now, I’ll forego the “wireless” part and just use a knob to control the thing. So, the small header is designed to take one knob as input.

In a coming post (when I get around to it), I’ll explain how the knob can actually be a very special magnetic absolute position encoder… for, you know, keeping track of the position of wheel modules which might spin more than 360 degrees at a time.

Here’s the knob wired up, along with some hall sensors.

… but from what are those hall sensors originating from?

The brushless Etek is my favorite Absurdly Large Load to test small controllers with. Everything from Turnigy airplane controllers to the DEC module has seen this thing. It’s both the largest “normal cheap motor” after Briggs and Stratton ditched the original Etek, as well as the smallest “big motor” that is easily available on the grey market.

I quickly whipped up some Arduino code using FVM as a guide for the state table. Overall, the process and structure are similar to what I made for Kartroller 6 – first arrange the outputs to account for the state of the system, then apply the throttle signal. In the case of Kartroller, the states were “forward” and “reverse”. With a BLDC motor like this, there are six states to cycle through to achieve one electrical revolution. “Reverse” on a BLDC motor is just stepping backwards through the table.

Here’s a video (10 megs .MOV) of some of the testing done with the Etek motor. Of course, it’s not a particularly strenuous test at all – the power supply limits itself to 3 or 4 amps at most. What it does show, however, is the built-in synchronous rectification topology that the IR21844s facilitate. Non-regenerative motor controllers will just let the motor coast if I let off the throttle, but a synchronous regenerative one automagically shuffles current in either direction to match the voltages between the motor back EMF and power bus.

Now, the problem with a power supply is that they generally do not approve of having current backfed into them. The voltage will spike as a effort to fight the inflow of current, and this power supply knew when to avoid getting hurt… That is why makers of regenerative controllers always advise putting a battery (or hugeasspacitor) in parallel between a power supply and the controller.

Well, that’s all for now. There are still three whole half-bridges left unused…

Deathblades: The Birds and the XBees

Jun 21, 2010 in Project Build Reports, RazErBlades, Reference Posts

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