Build Log:  Part 16

Well, hi!

First off, I feel an apology is necessary here – I haven’t updated my log in a LONG time, and I should have.  I’m sorry.  Since last we spoke, I’ve had a move across the country to Munich and started a new job with a cool biotech firm, and that’s been occupying a big chunk of my time.  I haven’t had the kind of space or free time to do the Enterprise justice, so I have been doing some Delphi coding and a couple of ocean-going ship models in the limited environment I’ve had.

However, I have a proper man-cave now, and I’ve been able to make some progress, so it’s time for an update!

In trials with that little Chinese MP3 player, I discovered that the power output from a PC USB port is anything but steady, and this resulted in the player re-setting itself at random intervals.  This had a really awful effect on my attempts to code a solution for the Big E, and I eventually scrapped it.  I didn’t find out about the voltage problem until well after I’d soldered together a very nice transistor setup on that board I showed you, and while the player was having fits being plugged into my laptop, I was left thinking I’d screwed something up in my soldering.  As it turns out, I had everything right, but the player just wasn’t up to the job.

So let’s talk about that player for a bit – given its sensitivity to voltage changes, it really isn’t a good choice for a model that has more than one sound.  If you’ve got just one sound or some background noise, it’s probably a solid play.  But for what I have in mind, it just won’t cut the mustard.

Instead, I went looking for, and retrieved, several different MP3 options.  My favorite so far, and one that does work for this job, is this:

It takes a micro-SD card, just like these little players, and is only just barely larger than one.  It’s called a “DFPlayer Mini”, and you can get them dirt-cheap on eBay.  Reference materials are widely available on the web, and they’re very easy to control from an Arduino.

Before I start digging into the Arduino code, I want to go into the soldering and setup of a PCB board with you first (skip ahead if this isn’t of interest to you).

 

 

I’m not a professional electrician, so if you have access to one, take their advice ahead of mine.  I’ve found this set of methods to be very useful, and feel it’s my duty to share.

Get the right size PCB board first – PCB means “printed circuit board”, by the way, it’s not some magic acronym or anything.  You want to accommodate not only your parts, but your fingers too. Try to imagine where it’s going to be mounted (in the model? in the base?) and what kind of height you’ll have available.

I’ll probably design my base with an inch or two of height in it, and since this model is so huge there will probably be some very big empty spaces in the base…so that’s where I’ll stick most of my controlling systems.  The TrekModeler board will go in the secondary hull, so I won’t have a kajillion wires going up-and-down the post.

You’re going to need wire – at least two different colors of insulated wire, and preferably one more spool of non-insulated.  (Non-insulated tends to be a little stiffer, too, which makes it useful for creating false ‘legs’ for soft wires during your breadboard testing.)  These shouldn’t cost you a whole lot, and can be had from Radio Shack, Conrad, or bought online.  Leftover speaker wire can work, but that can be a bit thick for this purpose, and hard to work with.

Some needle-nose pliers are also going to come in handy, although you could probably use a wooden chop-stick from takeout Chinese to get this job done too.  Wire snips are a big help (kitchen scissors work, but are kinda large and you might end up blunting them).

Many electrical parts require properly-metered resistors to go with them, and of course longer wires from the board to reach your lights and so on.  Although it is possible to mount them on a PCB and thread all the “feet” together, I find that using little ‘horseshoes’ of uninsulated wire to connect the parts makes things slightly clearer when looking at the board.  For some reason, I also find it easier to get my parts to sit more cleanly when using horseshoes.

To make a horseshoe, just take some uninsulated wire and wrap it around one point of your needlenose pliers (or a chop-stick) and snip off the excess.  Using those needlenose pliers, you can then grip the horseshoe by its middle and insert the legs into the holes on the PCB you want them in.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When soldering, a key rule to remember is “less is more”.  You only want to use just enough solder to fill the hole in the PCB and cement the legs of the parts inside it.

 

 

 

 

 

You don’t want a great big glob on the board, and you absolutely don’t want spill-over to connect other parts of the board (these are called “shorts” – they’re responsible for the term “short circuit”, which is generally an undesirable connection that can potentially damage your components).

 

I went into a little detail in my last installment about how the functions of the program are going to work…but after looking it over I’m going to have to be more detailed than that in order to ensure I don’t bork something up completely.  It’s going to be a rather extensive wiring setup, and I’ll use one other 3^rd-party item, a lighting board from TrekModeler (at least, I think I’m going to use that – I haven’t run current through it yet, so at this point I’m assuming that it will do the job I want) to handle the lightup and power-down.

Some of this may get a little tedious, but you really have to be tedious when you’re designing an embedded software program with electronics – once it’s in, you aren’t going to get much chance to change it.  (Where I position the controller will make this easier, but let’s assume for the sake of argument that you aren’t going to have that option.)

Here are the main routines as I envision them:

• Startup – initialize everything to idle
• Sleep – put the model to sleep
• Wake – wake it up from sleep
• Event – button got pressed, or some other trigger occurred
  • Check to see if event end time is here – if so, switch to idle
• Reset – shut down anything currently going on and re-intialize
• PowerUp – perform main-sequence music and lights
• Power-down – shut down completely
• BattleStations – Toggle (Red Alert on, or standing down from)
  • Makes Fire commands available
• FireTorps – torpedoes fire
• FirePhasers – phasers fire
• Warp Toggle – go to warp or return from it (sound and lights)

Routines that aren’t going to be invoked by user choice, but will be needed, include:

• MP3 controls
  • Play (int Track)
  • Pause
  • Next
  • Prev
  • Volume
• Check PlayTime (This determines how long the model has been active – because of a limit in the clock of the Arduino, it rolls over after about ~50 days. Since most of my tracks are timed to sequence with lights, I need to reset my timing if it has rolled over.)

These functions will revolve around physical components in the model, which consist of lights, and available sound resources, stored on the SD card in the chip’s socket.  The lights, listed out as circuits, are:

• Warp engine interiors, engine crystals, deflector dish (blue), and the impulse crystal
• Impulse engines, deflector dish (amber), and impulse crystal
• Interior lighting
• Floods
  • Upper primary hull
  • Lower primary hull
  • Secondary hull sides
  • Front engines
  • Rear engines
  • Pylons
  • Neck
• Nav lights (the slow-blinking ones on the sides and front of the primary hull)
• Anti-collision (fast-blinking on primary and secondary hull)
• Shuttle bay
• Torpedo room (when ready to fire, the launchers show red)
• Torpedo launchers
• Phasers

Sound resources on the SD card are:

• Ambient/idle
• Warp
• Torpedo fire
• Phaser fire
• Red Alert
• Startup Music

We’ll now build a “user story” to indicate what the model does in response to user action, and when it is able to do what.

1. User turns on power
   1. Initialization – turn on the MP3 player, turn on the extra board, enable any lights that are not subject to controls
2. Arduino program loop begins:
   1. Check sleep timeout – if the model has been awake and no one has touched it in a while, put it to sleep
   2. Check total playtime (50-day runout of counter, make sure we don’t overrun that clock in the controller’s CPU)
   3. Check to see if the user asked for an action
      1. If so, perform that action
   4. Is there an action running?
      1. Has its time run out?
         1. If so, return model to idle state
            1. Basic Power: interior lights, shuttle bay
            2. Play idle sound

The user can ask for certain functions only at certain times – for example, firing a torpedo can only be done after going to Battle Stations/Red Alert.  Here’s the breakout of how those functions relate to one another, and which ones become available when:

• Initialization – this is the root event on which all others depend
  • PowerUp
    • Play intro music, switch to ambient after done
    • Lighting sequence:
    • Bridge
    • Pylons
    • Engine forward
    • Neck floods
    • Engine aft
    • Aux control
    • 2ndary hull sides
    • Deflector dish to impulse
    • Nav and anticollision somewhere in there
    • Events available:
      • Power-down (reduce lighting to state like just after initialization)
        • This plays the ambient noise
      • Sleep
        • Turns off sound
        • All lights turned off
        • Available functions:
          • Wake
            • This is same as “initialize”
          • Warp on/off
            • Play warp sound
            • Switch impulse engines off
            • Change deflector dish and impulse crystal to blue
            • Start warp engine interior and crystals
          • BattleStations on/off
            • Play Red Alert sound, ambient sound after that
            • Turn on torpedo bay backlight
            • Available functions:
              • Fire torpedoes
                • Play torpedo sound
                • Lights to fire tube 1
                • Play torpedo sound
                • Lights to fire tube 2
              • Fire phasers
                • Play phaser sound
                • Alternate phasers on/off while sound is going
              • Return to normal (I’m also going to include a five-minute timeout so that after five minutes of no action while at Red Alert, the ship will return to normal state)
                • Returns to powered-up idle state
                • Powers down weapons
                • Play ambient sound

To accomplish all this, we’re going to need wiring, software, and some work.

With any wired system, I recommend you first assemble your wiring harness outside of the model, using a breadboard and jumper wires with sample LEDs.  You’ll save yourself a lot of tears if you do this first, because if you don’t, and you make any kind of error, you’ll have to either fix it or live with it, and both of those are painful.

To help, there are quite a few apps available free online that can help you.  I’ve used one called “Fritzing” to help me put together my picture of what will be needed to connect to my Arduino.

I still intend to use a Nano, by the way, but it’s easier to visualize in the Fritzing interface using an Uno.  Here’s what I came up with:

Note that I’m only including a single LED attached to the TrekModeler board in this diagram – there are many more, but I didn’t feel it necessary to lay them all out here.  This board also comes with two momentary switches, which are intended to be mounted on the model’s base and can control the power-up and warp-impulse switching.  I’m going to use transistors that are under the control of my Arduino as momentaries here, in effect my software will pretend to be the finger pushing the button.

I also have a little old PC speaker connected to the system for testing.  I’ll change that for a headphone jack when it goes into the real base.

This diagram does not show my phaser setup, which will connect pins A2 and A3 as my phaser controls.

When assembled on a board with the TrekModeler controls all hooked up, the entire thing looks a bit like this:

Not pretty.  It’ll look better soldered into a PCB, I promise.

I put some push-buttons on the setup which aren’t in the diagram, to enable manual testing.  These are on pins 2, 3, and 4.

If you’re going to code this yourself, have at it!  Just remember to comment liberally and informatively, always focusing on the ‘why’ a thing is there (readers will be able to figure out what is there just by looking at the code).

I’m probably going to end up packaging and selling this thing as a lighting harness for the ship, so I hope you’ll forgive me if I hang onto the code I’ve written.

Next time I do a write-up I will have run through a complete test of this wiring harness and moved it onto a PCB.  I might do a video of that part as well, not sure yet.  In any case, thanks for stopping in again and I’m looking forward to passing on more news as I get back to work on the Big Lady.

USS Enterprise – Build Log Part 15