Kimball Willard

I often get asked to help out with odd projects. I’ve done electronics for several displays at the St. George Children’s Museum, as well as having consulted on several themed environments (Jungle Land at Mersal Village in Jeddah, Saudi Arabia, the now defunct Pirate Island Pizza, and Tuacahn Amphitheater, to name a few).

During the Corona pandemic, the St. George Children’s Museum has been hard at work building some new environments, and fixing up older displays. One display they had me work on was in the Transportation Exhibit (sponsored by SkyWest Airlines). In it, the have a “luggage scanner”, which has a a display showing a looping video about SkyWest. When luggage is passed through the “scanner”, a break beam is triggered, which is supposed to show one of four possible luggage “scans”. Thing is, it never worked quite right.

I had given the onsite tech some diagrams for how to wire up some relays. The idea is that the break beam sensor would trigger a relay hooked up to an Arduino. The Arduino would then randomly trigger one of four relays connected to the MedeaWiz Sprite, which would play on of the four possible scan videos.

One issue I discovered was that the relay accepting the break beam sensor was a solid state relay. Now, if you’ve ever used relays, a mechanical relay doesn’t care if you’re triggering AC or DC. But on a solid state relay, it matters. If you use an AC Solid State Relay, once the relay is triggered, it will always pass DC current. We’ve been moving all relays in use at the museum to sold state relay, so you don’t get the mechanical “chunk” sound as the relay turns on and off. For some reason, during Corona, I couldn’t find DC to DC Solid State Relays anywhere in the US, only out of China, which was further delayed due to the pandemic. So, I’ve had to use mechanical relays (until my Solid State Relays show up).

One thing they did do was to use a Sprite Video Player Input Adapter. This adapter will take up to 8 contact relays, and send information into the Sprite Player as Serial commands, since natively, the player will only accept one contact play command. This never worked correctly for them (I get the feeling the chips on the device got fried during experimentation).

My idea was to use the Arduino to communicate directly to the Sprite using Serial. The first issue was I had to order in a TRRS to wire terminal adapter, so I had a point to wire in on (and I couldn’t use the Sprite Video Player Input Adapter, since it has translation chips embedded on it).

As I went through the device manual, the manual recomended passing all Serial commands from a PLC through a MAX3232 chip, to ensure RS232 commands were read as TTL. Well, I tried this. I knew I was close to getting this working, because when I would send a serial command, the base looping video would reset. I tried several permutations of wiring configurations, as well as Serial command structures (“Send one byte, Decimal 1 (Binary 0000 0001, Hex 01) to play file 001.xx”, etc). No luck.

As I read more on the MAX3232 chip, and is use on Arduino’s, I realized the Arduino is sending and receiving as TTL, and many makers use MAX3232 to translate into and out of RS232. So, I experimented wiring directly to the Sprite from the Arduino. After going through the command permutations, I finally was able to get everything working.

So, here’s how to wire it up. As you’ll see later in the code, I’m using Digital Pin 10 as Rx, and Digital Pin 11 as Tx on the Arduino.

When communicating over Serial, Rx is sending to Tx, and Tx to Rx. On the Sprite, you can have a looping video, with the name of 000.xxx (there are a large number of video file formats supported. We used mp4, so our file is 000.mp4). Triggered files would then be 001.xxx, 002.xxx, etc, up to 200.xxx.

Below is the code I’m using. Once I got it figured out, coding it was pretty strait forward.

#include <SoftwareSerial.h>

#define DELAY 23000 // 23 second delay while the video plays.
                    // Video is actually 18 seconds, but this gives it some leader time
#define rxPin 10
#define txPin 11

#define Sensor 4 // relay from break beam sensor

int sensorState = 0;
int lastSTate = 0;
int randomNumber = 0;
int prevRand = 0;

char one; // video one
char two; // video two
char three; // video three
char four; // video four

SoftwareSerial mySerial(rxPin, txPin);

void setup() {
  one = 1;
  two = 2;
  three = 3;
  four = 4;

  pinMode(Sensor, INPUT);
  digitalWrite(Sensor, HIGH);

  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);

  Serial.begin(9600);
  while (!Serial);
  mySerial.begin(9600);
  randomSeed(analogRead(0));
}

void loop() {
  // Read the sensor state
  sensorSTate = digitalRead(Sensor);

  // check if the sensor beam is broken
  // if it is, the sensorState is LOW
  if (sensorState == LOW) {
    // Randomly choose a relay to fire
    randomNumber = random(1, 4);
    if (randomNumber == prevRand) {
      randomNumber = random(1, 4);
    }
    showVideo(randomNumber);
    delay(DELAY);
  } else {
    delay(500); // If beam isn't broken, recheck in 1/2 a second
}

void showVideo(int id) {
  if (id == 1) {
    mySerial.print(one);
  } else if (id == 2) {
    mySerial.print(two);
  } else if (id == 3) {
    mySerial.print(three);
  } else {
    mySerial.print(four);
  }
  prevRand = id;
  Serial.println(id);
  Serial.println("");
}

It is possible to use the base Serial, and ports 0 and 1 for the Rx/Tx. By using the SoftwareSerail package, and another set of ports, you can use the Serial Monitor and println statements to monitor the application (old school debugging techniques).

The last change I may make is using a relay to fire when the beam is broken. I’ve used small break beam sensors directly into the Arduino in the past just fine. The break beam they used is a commercial unit, powered externally (which is why they chose to use the relay, for circuit protection). Since this has been in place for a while (just playing the base looping video), I haven’t been able to get the specs on the sensor (which is why I’m leaning towards using the relay). I’m installing later today, so I may give an update.

UPDATE – The break beam sensor they are using is a 12v dc unit. The relays they have on hand are 5v dc relays. They’ve played around with step down transformers, to transform the 12v dc to 5v dc. They can get the relay powered up, but not trigger correctly. Rather than mess with all that, I found a DC-DC relay circuit that can be powered from 3 – 32 v dc (and can trigger 3 -60 v dc at up to 2 amps). I’ll be putting that inline when is shows up (soldered to a breadboard with terminal block headers to make it easier to deal with).