Category: project

Triumph Renovation part 1: Greek, Thracian, Macedonian, and Persian

I’ve started playing Triumph. After building a few armies out of my existing DBA figures, I decided to build up my armies to better work with Triumph. Depending on the army, this means either rebasing elements or painting new ones to increase the size of the force.  I’ve had to do a little of both, to get my Classical armies up to date.  Clearly I need to adjust my depth of field  and get some better lighting before I take too many more pictures.

I started with figures I had on hand that extend the armies I already have painted. My first batch was enough Greeks and Thracians to at least be able to field single armies.

Now that Greek Hoplite armies are mostly Heavy foot but with some Elite Foot, I need both more elements in total and some different elements to distinguish between Heavy and Elite.  I painted up some Essex Later Hoplite Greek figures wearing metal breast plates to represent Elite Foot, as well as a dedicated general and a few more linen armored units.  Everything is hand painted including the shields, but my decreasing eyesight is becoming apparent.  Along with my 12 Spartan Hoplites this is more than enough to field most Hoplite-heavy Greek armies or a Persian triple army mercenary Hoplite contigent.

Newly painted Essex Later Greek Hoplites, 15mm

The other major change in Greek armies was reclassification of light troops from Psiloi to Rabble.  I had 2 elements of Greek Psiloi that I rebased as Rabble, and eventually I painted some more to bring it up to 4 rabble. The paint jobs were close enough that none of the figures stand out, once they’re based consistently.  I also painted 3 elements of Thracian Light Foot to augment my Thracian army.

Thracian light foot in the front; Essex figures with maybe a few Old Glory? Rebased Greek Rabble in the rear; Essex 15mm
A combination of rebased and newly painted Greek Rabble: mostly Essex, some Old Glory.

Along with the Greek Rabble, I also painted a bunch of Javelin Cavalry for my Alexandrian Macedonian army. Most of these represent Thessalian Cavalry, but there’s also an element that is more plausibly Thracian.  This is a mix of Magister Militum (Chariot) figures and Essex 15mm. The size difference is apparent if you’re looking for it, but not so bad when they’re based consistently and with only two horses per element.

Newly painted Greek and Thracian cavalry for Alexander the Great. Essex and Magister Militum 15mm

Thinking a bit harder, I don’t remember what order I painted all these in, so I might’ve gotten some of it wrong.  In any case, I also needed way more Hypaspists for a triple Alexander the Great army, and my existing Hypaspist needed to be rebased as Raiders.  I could’ve chosen Pike, but I don’t yet have a full set of Alexandrian pike yet, so I decided to make the Hypaspists Raiders for variety.  These were Old Glory figures I got from JM unpainted.  I declined to paint even more Alexandrians looking like clowns, and chose more straightforward colors for their armor.  The shields and plumes are enough color for these elements. I also had a few elements that were previously “4Ax,” but the closest equivalent in Triumph is Greek Mercenary Peltasts (Light Foot); so, more rebasing…

Newly painted Alexandrian Hypaspists: Raiders; Old Glory 15mm
Rebased Hypaspists (Raiders) and Greek Peltasts (Light Foot); 15mm Essex

Next are some mostly rebased Persians, augmented with newly painted Light Foot. I had 4 stands of Persian 3Ax with identical figures on each set of 2 stands, as well as 6 more identical unpainted peltasts.  I painted the 6 remaining guys and rebased everything with different figures on each base for variety.  You can find the newly painted figures if you look hard enough, but the paint jobs are close enough to match well.  I also rebased a bunch of DBA 3Cv stands as Javelin Cavalry, including the general, who is no longer allowed to go into battle on a chariot.  Good for morale, bad for King Darius’ hemorrhoids.

Persian Light Foot; Essex 15mm. Mostly rebased, with the guy sticking his arm out to the right on each stand newly painted.
Rebased Persian Javelin Cavalry; 15mm Magister Militum (Chariot) and Essex.

At this point I have a lot of options for an Alexandrian Macedonian triple army in Triumph, and limited choices for Later Achaemenid Persians. I may pick up some more Light Foot figures for the Persians, but I have enough mounted troops for now.

Rebasing figures that were originally based on metal bases, attached with either super glue or epoxy, is basically not a problem at all. The figures can be removed easily with an X-acto chisel blade, and it gives me an opportunity to update my basing. I’m not sure how difficult it will be to remove figures from wooden bases.

Running tally of Triumph Conversions

  • Newly Painted: 22 elements; 73 figures
  • Painted/Rebased: 7 elements; 8 figures painted
  • Rebased Elements: 12 elements

OpenForge: 3d Printed Dungeon Terrain

The availability of a large selection of models for wargaming and RPG terrain was a huge factor in deciding to purchase a 3d printer. Here are some examples of OpenForge dungeon tiles I’ve printed and painted.

OpenForge dungeon tiles and Carrion Crawler models printed in PLA.

Because OpenForge 2.0 “low wall” pieces weren’t available when I settled on what I was going to print, I decided to drop the wall height by 15mm everywhere. This makes things more visible in tight spaces while keeping it visually interesting, but unfortunately the doorways don’t line up perfectly.

I settled on using magnetized bases: each base has a spherical magnet at the edge of each 1″ square, which allows the pieces to align and stay aligned during use. It’s not a strong connection, but it works fine for single floor dungeons.

The first image is an encounter I set up for a D&D game I’m running with Ezra and some of his friends. This is the tower in Thundertree (from the Mines of Phandelver introductory adventure) some time after another group of adventurers came through and killed the dragon.  Carrion crawlers and insects now inhabit the area, preventing local loggers from using and restoring the tower.

A selection of painted and unpainted OpenForge dungeon tiles

Halloween 2018: Ezra’s Death Gun Costume

Ezra’s Death Gun costume

Another year, another Halloween costume!  This year Ezra chose the character Death Gun from the Anime series Sword Art Online II.

This one was supposed to be pretty easy: a mask, a cloak; maybe some arm coverings; he wasn’t allowed to bring costume weapons to school anyway.

Nothing is ever as easy as it’s supposed to be, though.

Death Gun reference image downloaded from tvtropes.com

We started with a foam head from the craft store, and a cool material called Sculpt-a-Mold.  This is basically a mix of paper pulp and plaster. After mixing water to form a pasty consistency, you can form arbitrary shapes out of it. Because of the plaster, it dries in only half an hour; but the paper fibers make it much less brittle than plain plaster.

After many iterations of shaping and sanding, we identified a few fatal flaws with the approach.  The mask was relatively heavy, but it was still too brittle to attach straps securely to it.  More importantly, starting with a head-sized base meant that the mask fit too tightly on Ezra’s face, making it impossible to breathe or even open his mouth.

The abandoned Sculpt-a-Mold mask

Solving this problem turned out to be a great excuse to get a 3d printer.  There was a model available on Thingiverse available, so all we needed to do was print, assemble, and paint it.

Even 3d printers that work well are a bit fiddly and require adjustment, experimentation, and maintenance to produce good results. I didn’t start printing this mask until I was confident I’d get good results, and overall, it succeeded. I didn’t have any completely failed prints, but there was a bit of underextrusion in the chin pieces, which led to a piece breaking off on Halloween night.

3d printed Death Gun mask based on a model from Thingiverse

The lenses were thin plastic from packaging material, painted with Testors transparent red paint.  We just glued them in, instead of using the lens holder pieces included in the 3d model. The mask itself was glued together using 5 minute epoxy, primed grey, and painted with craft acrylics.  I didn’t make any effort to smooth the surface prior to painting, and it turned out fine.  The printing layers aren’t really visible, but the polygonal facets of the 3d model can be seen in the finished product.

3d printed Death Gun mask

The cloak was made from a pattern and fabric found at Jo-Ann Fabrics. We tried several techniques to get arm wraps like Ezra wanted, but they didn’t work well, so we abandoned that.  Under the cloak, he wore all black, with the black strap chest harness we made for the Gaara costume.

This wasn’t the most satisfying costume project, but it turned out well,

Halloween 2017: Ezra’s Gaara Costume

Woohoo, I’m not an entire year late yet!  Since I have some newer projects I’d like to post, here’s an older one I haven’t gotten to yet.

Gaara costume
Ezra as Gaara
Gaara
Gaara

Ezra’s Halloween costume for 2017 was Gaara: a character from the Anime/Manga series Naruto.  The main props we needed to build for this costume were his sand gourd, and the leather bandolier. The clothing portions were all done with street clothing for simplicity.

Here are a few pictures of the finished costume, with a few more showing how it was constructed and made to work.

Gaara costume, backGaara manipulates sand, and so he always carries with him a giant gourd-shaped container made of sand. This prop defines the character, but it’s huge and potentially unwieldy.  Construction was theoretically simple: use paper mache.  However, it wasn’t easy.

As a base, we used punching ball balloons, chosen because they’re larger and thicker than ordinary balloons. For our first few attempts, we taped the balloons together before applying paper mache.  This was a problem when one of the balloons deflated, and the half-finished shell shrank and wrinkled.  Extracting the bad half and replacing it didn’t work well, so we eventually ended up building up the second balloon separately and attaching them with masking tape and then paper mache after the shell was hard.

Gaara's sand gourd prop
Gaara’s sand gourd prop

The cork on top was a natural cork from the craft store, and the lip was formed using Crayola Model Magic, which is basically an air-dried clay with the consistency of foam.  It’s easy to work with, light, and takes paint well.

The whole giant peanut was painted tan, and then the seals were painted on after tracing the outline from a stencil, and cracks were hand-drawn.

Gourd harness
Test fitting the gourd harness. It’s usually worn under his shirt.

After the gourd was completed, it was obvious that the decorative pleather bandolier would not be strong enough to support it without it sliding around and looking horrible.  To solve this problem, I constructed a harness out of leftover nylon straps and buckles.  The picture here shows Ezra trying on the harness for fit. In actual use, the harness went under his black shirt, and the attachment buckle went through a small hole in the shirt.

Gaara costume, side view
The leather bandolier and buckles are slightly clearer here

The buckle was sewn to the red sash around the gourd, and clipped onto the harness.  This made it removable, so he could take it off at school, and supported the weight completely without putting any stress on the leather bandolier.

The leather bandolier was not difficult: I made a pattern out of paper, cut, and sewed it up.  The multiple matching metal buckles came from a snakeskin leather purse from the thrift store, and were hot-glued into place.

The pleather came from one of our many trips to Pittsburgh Center for Creative Reuse, and the white sash and foot wraps were muslin cloth. He rounded it out with red hair dye and Halloween face paint for the eye liner. The forehead tattoo worked better with acrylic paint than cheap Halloween face paint.

No User Serviceable Parts Inside

It used to be that electronic devices were printed with the warning, “No user serviceable parts inside.” That was never true, and it still isn’t. They’ve stopped printing this on most devices, but not because it isn’t true.

Instead, they’ve eliminated any obvious way to disassemble the device. This prevents people from hurting themselves if they’re skilled enough to use a screwdriver, but not skilled enough to avoid shorting a capacitor and blowing themselves up. Luckily, it doesn’t prevent people from learning how to repair things themselves.

Ezra’s hand-me-down iPod had a failing battery. Instead of buying a new one, or paying to have the battery replaced, we got him a battery replacement kit for Christmas, and shared the experience of disassembling and repairing the device.

No User Serviceable Parts Inside?
Ezra unscrews an RF shield

The procedure went smoothly, but not perfectly. Unfortunately the home button did not function after we were finished with it, but Ezra wasn’t bothered by this, since he already uses an on-screen home button. He declined my offer to order another replacement part, and now he knows what the inside of an iPod looks like.

 

Wooden Weapons

The kids aren’t allowed to get wooden weapons at the Renaissance Festival, because then I don’t get to make them.

A wooden hammer (maul) prop I made for Ezra’s Dwarf costume. Wooden curtain rod, pine wood head, craft foam and fake leather on the handle.
Details of the hammer head show the Gunnerkrigg Court symbol carved into the side of the head, just as Ezra requested.
Short swords for Martine’s Ranger costume. Pine board blades, and masonite reinforcement at the hilt. Handles wrapped with pleather.
The props in use.

 

Fantasy Dwarf Helmet

Before I can post this year’s costume creations, I need to do last year’s.

Here are some in-process photos of a fantasy Dwarf helmet I made for Ezra’s costume last year.

It all started with a baseball batting helmet I found at Pittsburgh Center for Creative Reuse, and some chunks of 2×4 I glued into blocks.
I cut the helmet down and roughed out horns on the blocks.
I carved the horns with a spoke shave, and sanded them. They’re bolted into the helmet using large lag bolts from behind, with hot glue to fill in the gap between horn and helmet.
Details were applied using flexible craft foam attached with hot glue.
I sprayed the entire helmet black, and then painted most of it metallic steel. After spraying a protective varnish, I added fur to the horns.
The finished costume included a “wizard” beard that we braided, scale armor made from aluminum flashing that I had when I was a kid, one of many home made cloaks, and a wooden hammer I’ll show off in another post.

Line6 FBV: Part 2

I’ve started looking into the Line6 FBV protocol again, after letting it sit for a year. This time, I had another Line6 pedal that is compatible with the Amplifi. By observing serial traffic between the pedal and amp, I was able to emulate the basic functionality of the pedal using an Arduino.

Hardware

I am vague in this section, because I do not know if the circuits I built are truly safe for the Amplifi hardware. I didn’t have any problems with the amp, but I did generate enough electrical problems via USB to cause my laptop to spontaneously reboot several times… that can’t be good, right? Any attempts to mess with your hardware will probably void your warranty, and a mistake could blow up your amp or burn your house down. You have been warned.

I used the same input/output circuit found on the FBV2 pedal. Sending data to the Amplifi did not work without both of the balanced signals on the cable. I believe this may be using RS-422 signaling, which requires that differential input. If so, a proper RS-422 chip might work better than the Schmitt triggers, but I haven’t tested it.

The serial specifications are the same as I used on the FBV2, and the same as MIDI uses: 31250 baud, 8N1. I used a higher serial speed for USB debugging channels, to reduce the chance of interrupting an incoming byte.

I assumed the connector wiring was the same as on the FBV2 pedal, and verified this is the case. However, the amp supplies far more than 5v, and the voltage will need to be regulated to be compatible with a 5v or 3.3v Arduino.

On the Arduino side, listening to both sides of an amp/pedal conversation, USB debugging, and controlling an LCD and buttons all at the same time was much easier using an Arduino Mega, which has multiple hardware serial ports. I wasn’t able to get SoftwareSerial or AltSoftSerial to do what I needed here.

I used an Adafruit character display I2C backpack with four on-board buttons to mock up a user interface. I can’t find this board for sale anymore on adafruit.com, so I’m glad I got an extra.

Protocol

The data sent between amp and pedal is sent in packets of the same basic format, and it matches what I found on the FBV2: “F0” followed by a length byte, and that many bytes of data.  The interesting parts are the messages those packets can contain.

By recording the traffic between the amp and pedal while interacting with the pedal, I was able to identify many of the features of the communication protocol. However, there are also spontaneous handshake packets sent between the devices, and I have no clue what they’re for.

The messages themselves start with one byte that identifies the type of message, followed by message-specific data. Messages sent from Amp to Pedal had message IDs with the high bit off (0x00-0x7F), and messages from Pedal to Amp had IDs with the high bit on (0x80-0xFF).

Here are the message IDs I have identified, with my hypothesis as to what each one is used for. I made up all the message names based on what I think they’re for.

01 00

Every ~100ms, the amp emits this Heartbeat message, and the pedal emits a standard response (80, see below).  I don’t know what this is for, but I assume it’s a heartbeat so the amp knows the pedal is still connected.

04 NN BB

I call this the LED message, because when it is sent, the pedal turns an LED on or off.  NN specifies which LED is changing state, and BB is 00 for “off” or 01 for “on.” Values of NN I have observed:

  • 61: Tempo. The amp flashes an LED on and off to mark the current “tap” tempo for effects.
  • 20, 30, 40, 50: Patch LED A, B, C, D
  • 21, 31, 41, 51: Unknown.
  • 02, 03: Unknown; Wah/Vol LED, maybe?

When patches are changed by the pedal, the amp responds with a set of messages to update the pedal state for the new patch. Included are an LED message for each Patch LED, configuring its state, as well as some of the other unknown LED numbers.

08 C1 C2 C3 C4

The Small Display message sends 4 ASCII characters. When the amp is in Play mode, a message is sent whenever the patch changes, with the characters representing the bank and patch, such as ” 01A”. When the amp is in Tuning mode, this displays the note the amp thinks you’re playing, whenever it changes.

10 NN DD C1..C16

The Large Display message sends a longer text message to be displayed on the pedal. In practice, I have only observed messages with NN=00 and DD=10, followed by 16 (0x10) bytes of ASCII data. I am guessing DD is a byte count. NN might be a line number if the target device has a multi-line display, but I don’t know of any such device.

In Play mode, the amp sends the patch name in this message whenever the patch is changed. In tuning mode, the amp sends a string of characters that visually depicts how far off-pitch you are from the note sent in the Small Display message.

For example, when the note is perfectly tuned, it displays:

I---- ** ----I

When the note is off-pitch, it uses > < arrows to point which way to tune the string.

80 00 02 00 01 01 00

Message 80 with this specific byte sequence is sent by the pedal in response to each Heartbeat message it receives. I don’t know what the byte sequence represents, and it doesn’t seem to change depending on the state of the pedal’s buttons or LEDs. It may be a device-specific ID or some other kind of identifying information.

If I remember correctly, I found the amp starts to spam packets at the pedal when the pedal stops responding to heartbeats. It was easy enough to add a response handler for this, so I did.

81 NN BB

The pedal sends this Button Press message whenever a button on the pedal is pressed or released. NN represents the button number, and matches the NN sent in the LED message response: 20, 30, 40, and 50 are used for buttons A, B, C, and D. BB is 01 when the button is pressed and 00 when it is released.

The “tap for tempo” and “tune” features are implemented in the amp, not in the pedal. The pedal tells the amp when buttons are being pressed, and the amp tells the pedal what to display; it’s up to the amp to interpret the button presses as a patch change, tempo change, or tuning request. This makes development of the pedal software much simpler, and allows the amp to change its features in firmware without requiring a new pedal.

82 NN VV

The Expression message is sent whenever the pedal’s expression pedal changes position. NN has always been 0 in the messages I observed, but it probably denotes which expression pedal is being adjusted, in cases where more than one expression pedal is supported. VV is the value of the expression pedal: 0-127.

Startup, Patch Change, Mode Change

The pedal powers up when it is connected to the amp, and after a brief pause sends a few startup packets. In full packet form, the pedal sends:

f0 02 90 00 
f0 02 30 08

Each line is one packet containing a message of length 2. The first one is message 90, value 0; the second one is message 30, value 08. This is the only case I’ve seen when the pedal sent a message without the high bit set. Either my interpretation of the message ID high bit isn’t correct, or I did not read the packet data correctly. I have no idea what these messages mean.

In response, the amp sends these two packets:

f0 01 40
f0 03 31 01 16

I don’t know if this startup sequence varies depending on the hardware involved, but it doesn’t seem to change depending on the device state.

Then, the amp sends packets containing a complete set of state to the pedal: Small Display, Large Display, and an LED message for each LED. The pedal only needs to remember these values and only change its LED and display when new settings are received from the amp.

Whenever the pedal sends button presses that are interpreted as a patch change by the amp, the amp replies with a complete state set, just as when the pedal starts up.

If the pedal user presses the button corresponding to the currently selected patch, the amp interprets this as a tempo change.  Shortly after, the tempo LED messages will start arriving at the updated rate.

If the pedal user presses the “tuning” button combination, the amp enters Tuning mode. In Tuning mode, the amp sends Small Display and Large Display messages in real time as the user tunes their guitar. Further button presses reset to Play mode.

The future…

Before I left for vacation in August, I made plans for a few devices. These plans are on hold until I get another flash of inspiration, unfortunately.

First, I plan to replace the microcontroller in my FBV2 pedal with an ATTiny85 running emulation software that implements the two FBV2 buttons as “next patch” and “previous patch.” It listens to the incoming packets to determine the current patch, and calculates the button value to send for the left and right buttons based on the current patch. I got as far as emulating this behavior on the Arduino Mega, but didn’t successfully emit messages from the ATTiny.

The ATTiny is inexpensive and small, but unfortunately its limited feature set makes debugging very challenging. I may have to build an amp emulator with the Arduino Mega, just to debug the pedal emulator running on ATTiny…

My second project was a full 4-button pedal with expression. I mocked up all of the required functionality on the Arduino Mega, using the Adafruit LCD character/button shield. I will replace the on-board buttons with beefy pedal switches. Tempo will be marked by changing the LCD backlight color, and all tuning and patch names are displayed.

When I was working on this more actively, I thought I might be missing a large chunk of the FBV Mkii controller’s functionality: MIDI over USB. Thinking about it again, I’m not so sure. It feels like it would be a lot easier to implement MIDI in the device driver rather than in the pedal hardware. Maybe the USB port is connected to the same internal serial lines as the RJ-45 connector, and the device’s drivers convert the simple button press messages into MIDI messages before they make it to userspace?

This is a fun project… sometimes. The rest of the time, I don’t work on it, because I’m doing something I need to do, or something fun, instead.

 

Reverse Engineering: Line 6 FBV2

The Line 6 FBV2 is a control pedal for use with older Line 6 amplifiers and effects processors. I bought it to use with our Line 6 Amplifi 75 guitar amplifier.  Unfortunately, it isn’t compatible with this newer amplifier, so it’s been sitting on the shelf for over a year.

After starting to play with an Arduino development kit recently, I decided it was time to revisit the FBV2 pedal to see if I could make it do what I wanted.

A quick disassembly revealed a single small circuit board with only 2 ICs and a handful of other components.  This looked like it might be easy to reverse engineer and see how it worked.

Line 6 FBV2 circuit diagram, approximately.

I followed the traces from the 8-pin RJ45 connector to the ICs and switches on the board, and drew a rough circuit diagram. Looking up the part numbers, I found an inverter and a microcontroller. The pinout from these parts let me identify the transmit, receive, and power pins on the connector.

The microcontroller is branded NXP, made by Phillips: P87LPC760. This doesn’t seem to be made anymore, so it seems not worth getting a replacement and programmer for it.  My first idea for making this usable was to read the output from this device and convert it into something my Amplifi 75 can understand.

I hacked apart a spare ethernet cable to use its RJ-45 connector, and connected the FBV2’s transmit, receive, and power pins to my Arduino’s breadboard.

FBV2 disassembled and attached to the Arduino

I had heard the Line 6 devices used MIDI, so I approached this as if it were a MIDI device. I didn’t bother building an electrically correct MIDI interface, which requires an optoisolator, because this device was being powered by the Arduino board (via my laptop), so there was no danger of a ground loop.  Besides, this device should already have an optoisolator if it needed one, but it didn’t; so how important could it be?

I wrote a sketch using the SoftwareSerial library to interpret the output of the FBV2 as a MIDI stream: 31250 baud, with the default start/stop bit options. I mirrored the bytes over the USB serial port to the serial debugger in the Arduino IDE to inspect the byte sequences emitted by the FBV2 when the left and right buttons were pressed.

After a bit of fiddling, I was able to read the output. There were 2 basic data sequences:

  • Left button: F0 03 81 67 01 F0 03 81 67 00
  • Right button: F0 03 81 20 01 F0 03 81 20 00

These certainly seemed like MIDI sequences, but they weren’t quite right:

  • F0: System Exclusive. This is typically followed by a byte sequence terminated by F7. I don’t see that, so I though perhaps the byte stream was automatically terminated by a control byte (<= 128 decimal).
  • 03: At first I assumed this was the only data associated with the System Exclusive event; but, see below.
  • 81 67 01: This is a Note Off event on channel 2; note 67, velocity 1. 
  • 81 67 00: Note Off, channel 2; note 67, velocity 0.
  • 81 20 01: Note Off, channel 2; note 20, velocity 1.
  • 81 20 00: Note Off, channel 2; note 20, velocity 0.

This was all very hopeful, but eventually I realized it may not be important what this device outputs. Instead of converting this output to whatever the Amplifi 75 needs, maybe it would be better to replace the microcontroller with something a bit more accessible, and just program it to output what I needed instead.

My next few lines of inquiry weren’t fruitful, but I have a plan for what to try next.

I decided to pop out the microcontroller, which was helpfully mounted in a socket, and attach a few Arduino IO pins directly to the microcontroller outputs. This effectively replaces the FBV2’s brain with my Arduino, allowing me to program it to output whatever I want.

I wrote scripts to test a huge variety of MIDI control sequences: Control Change and Program Change events on all different channels with different controls and values, and the original MIDI-like sequences produced by the FBV2 pedal. Nothing seemed to be recognized by the Amplifi 75.

What I really need is a pedal compatible with the Amplifi that I can reverse engineer and see how it works. But if I had that, I wouldn’t need to make the FBV2 work, and there would be no point to completing the project.

It got late enough that I tore everything down and put it away. 

Then, after a bit more searching online, I found some information that will give me a new start. A company called VLoTech created a github project that reads and writes FBV pedal board data, for the larger FBV pedal boards that are compatible with the Amplifi 75.

This project showed me that the F0 03 sequence is more likely to be a byte count for the subsequent commands.

I also realized that I didn’t measure any timing information from the FBV2 when I read its data sequences.  It may be that the F0 03 81 67 01 and F0 03 81 67 01
sequences are “on” and “off” events that need a time delay between them in order to have an effect on the target device.

Next time I pick this up, hopefully later this week, I plan to try some of the other byte sequences documented in the fbv_tools project. 

To be continued…

    DBA Army III/70b: Georgians

    Here is my recently completed Georgian army for DBA 2.2+.

    DBA Army III/70b: Georgians. Essex miniatures.
    Georgian 3Kn General and 3x3Kn.  Essex Miniatures.

    I painted this army for the God Wills It! First Crusade Campaign Theme, which will be run on Saturday night at Fall-In 2013.

    The primary factor for me choosing this army was that the slot was still available in the campaign.  However, I also had a number of the figures on hand, as leftovers from other projects.  I chose the rest of the figures based on what Jack Sheriff used in his Georgian army.

    Unlike Jack’s figures, most of mine are stock, unmodified Essex miniatures.  The exceptions are four Light Horse models, which were Bulgar archers.  They had large toggles on the front of their coats, which I removed to make them look almost identical to the Essex Kipchak/Cuman figures.

    III/70b: 4x2LH. Essex Miniatures.
    III/70b: 2x4Sp. Essex Miniatures.

    The Knights are a mix of Essex Georgian knights and other similar knights.  The general and his supporting figures are a generic Eastern European command set.

    I had a hard time finding any definitive information on colors and shield patterns for this army. I would not use this army as an example of what Georgians are supposed to look like.  I was inspired by a few other painted Georgian armies online, and pictures of

    As usual, these are painted primarily with Vallejo acrylics. I use a combination of painted highlights and several colors of ink washes for shading.  Shields are hand painted.

    III/70b: 2x3Bw. Essex Miniatures.

     

    III/70b: 2x2Ps. Essex Miniatures.