Sunday, August 17, 2014

Baseball Scoreboard - Things I'd Like to Improve

    While quite a bit of development has gone into this project thus far, there are still some things I see as shortcoming.  After the jump, I'll go through the things that I see as needed improvements.  If you see anything I may have missed, please feel free to chime in in the comments below.



Constructing the Scoreboard


Issue #1 - Display is not bright enough
     Discussion:  As awesome as the scoreboard is indoors, as soon as you get it outdoors, it becomes much less awesome.  In short, when exposed to direct sunlight, the display is too washed out to read.

     
As you can see from the picture above, the signal is so weak (and the exposure of the camera exposure so quick) that you can't even make out the full display.  I've found this effect can be mitigated somewhat by using a shade (pictured) and orienting the scoreboard to take advantage of the sun's position in the sky, but the display outdoors never gets all that bright.
    Resolution:  Unfortunately, I don't see any easy way to solve this.  I tried polarizing filters with no luck.  Every other solution seems to involve increasing the brightness of the display.  Unfortunately, it looks like I need to increase brightness by an order of magnitude and that means massively more power.  As everything is powered by USB external battery, more power means less time that I can keep everything up and running.  In it's current configuration, one battery gets me 4-5 hours of uptime.  My fear is that attempting to increase brightness would not only be technically difficult, it would also result in a huge increase in battery size required.

Issue #2 - Scoreboard is not waterproof
    Discussion:  Because this is a prototype (and baseball is by and large a fair weather sport), very little was done to waterproof the board.
    Resolution:  This should be relatively straightforward.  The only significant issue I see here deals with the waterproofing of the LED displays.  As the displays are already hard to read (see above), material selection is key to preventing additional attenuation and/or glare.

Issue #3 - Cables don't match size of board
    Discussion:  This is really a side effect of not having the final design nailed down prior to reaching the cable fabrication step.
    Resolution:  Relatively straight-forward.  Just need to put the time into prefabricating the cables.

Programming the Scoreboard


Issue #1 - Full help message does not display over serial
    Discussion:  For some reason or the other, once the help message gets over a certain size, it fails to display.  As a result, I only display the top level help information (detailed information is commented out).
    Resolution:  This was so reliably repeatable, I'm sure it's just something stupid I'm doing (like writing too many characters to a buffer or failing to clear the read buffer after a certain point).  Just a time and effort issue at this point to troubleshoot the exact cause.

Issue #2 - 3 Panels are treated as one continuous matrix, complicating programming.
    Discussion:  This is entirely a side effect of trying to use the adafruit library as close to as-is as possible.  In the process of commenting my modified library (to post here), I noticed the following lines in the HT1632_GCScoreboard.cpp library file:

31:     matrices[0] = HT1632(data, wr, cs1);
32:     matrices[1] = HT1632(data, wr, cs2);
33:     matrices[2] = HT1632(data, wr, cs3);

Looking at these lines, it occurred to me that it probably would have been easier to treat the three panels as separate entities rather as one.  In essence, I figure out where each panel is located in the virtual 3 panel display and provide coordinates that the library then reverses to figure out which panel to talk to (i.e., I do work in the program that the library then has to undo to get the job done).
    Resolution:  This is more of a coding purity problem for me (i.e., it work much more efficiently if I did it this way) than a functional one.  In other words, the fix is one that it immaterial to the fans, appealing only to my desire to have better code.  The fix is not terribly difficult, just tedious -- once I change the underlying library, I then have to find every reference in the code and change it accordingly.

Issue #3 - Top/Bottom Inning indicator is not clear
    Discussion:  In field tests, fans consistently get hung up on figuring out what half of the inning we're in.  Right now, the left display contains the top/bottom inning indicator (either an up or down arrow) and the right display contains the number of the current inning.  Even when explained, this still seems to be a problem most fans have a problem keeping straight (it's the most common question I hear from fans even when they are looking at the scoreboard).
    Resolution:  I'm at a loss for how to fix this one.  Given the limited display space, I have very few options here.  I like how top/bottom of the inning is communicated on the MLBRecap screen (an arrow below or above the inning number), but am currently unable to do the same for inning within rolling yet another, smaller font.  Any suggestions are appreciated.

Issue #4 - Message command causes constant blinking of the display as message rolls left/right (could be a seizure hazard)
    Discussion:  Not only is it a seizure hazard, it's also annoying as crap.  Not only does the display with the message blink, all of the other displays do as well.  This would be mitigated a bit by treating the three LED displays as separate entities (above), but is still less than an ideal solution.
    Resolution:  Since the display can hold two lines of text at a time, I have two ideas to solve this:
  1. Display two lines of text at a time for a few seconds before moving on to the next two lines
  2. Display the first two lines of text at first and then have the message scroll up until done.
Both ideas should be relatively easy to implement, just need to make the time.

Control Box Overview


Issue #1 - Box overheats in direct sunlight
    Discussion:  Over the course of a number of game I learned that if I don't keep the control box in the shade, it will reliably overheat.  In further troubleshooting, it seems that the problem is the 4G Hotspot.  As it's black, it retains heat pretty readily and will shutdown when too hot.
    Resolution:  As it seems that the problem is tied to heat absorption from the sun (it's never overheated in the shade), shielding my one black component from the sun should fix the problem.  Should be relatively easy to fix but has been a relatively low priority for me, as this problem is easily avoided.

Issue #2 - Raspberry Pi needs reboot if network adapters don't instantiate automatically on boot
    Discussion:  I find that if I fail to boot the hotspot prior to applying power to the Raspberry Pi, I usually am unable to get the scoreboard to work correctly without a reboot.  It seems the problem is that if the hotspot is not fully up, it will not instantiate automatically as an ethernet adapter.
    Resolution:  The best solution is to have and follow a start-up guide.  As I know people rarely RTFM, a mitigating solution would be to have the Raspberry Pi poll every few seconds until the adapter comes up in order to make sure routing is set up correct (which probably also means I'll need to rerun some of the packet forwarding scripts as well).

Issue #3 - Need a "how to start up" guide  to ensure things come up in correct order to maximize chances everything instantiates correctly(physical construction of scoreboard).
    Discussion:  Even for me, remembering to start things up in the correct order can be a problem.  Failure to start things in the right order can result in the networking not coming up right.  This could be mitigated by changing making network startup more robust (see above) or changing power management (see below).  A written startup guide could help solve these issues.
    Resolution:  A small 1,2,3 startup guide attached to the control box should address this need, helping the user start up things in the order that maximizes the chances that everything starts up correctly.

Issue #4 - Power management
    Discussion:  As this system operates solely off of batteries, power management is always a design consideration.  In the interests of getting a system fielded quicker, right now it runs off of three different batteries.  This causes problems in two different ways:  1)  Equipment has to be powered in a certain order to ensure everything comes up correctly and 2) three different batteries have to be charged between uses.
    Resolution:  The existing equipment can all be powered off of one device (the existing battery has a charging port for the AP and the hotspot can be powered by the Pi.  Two concerns need to be checked out prior to going with this solution: 1) Current draw for the scoreboard plus AP may be more than the Pi's USB bus supports and 2) Moving everything to one battery will likely mean a larger capacity battery in order to make it to the end of two games (approx 5 hours).

Network Configuration


    Issue #1 - Can't turn 4G Hotspot AP all the way off
    Discussion:  The hotspot, by design, bridges WiFi and 4G networks.  Since we are using the WiFi from another device, the WiFi in this device unnecessarily consumes battery power and could potentially cause confusion for the iPad (if it has been joined to both the scoreboard AP and 4G AP in the past).
    Resolution:  Unfortunately, the only resolutions for this seem to be either custom firmware or the replacement of the 4G hotspot with a different solution; so fixing this is a longer term proposition.

The Parser


    Issue #1 - Hooks for Score recaps exist, but no feeds are openly available to use
    Discussion:  Originally, this was a fan request that came up during testing.  I envision using this functionality between halves when the center display is not being used for anything else.  All of the scoreboard elements are finished for this feature, but the code that runs on the Pi was never started.
    Resolution:  Unfortunately, for the games fans care about (MLB), I could only find feeds that require subscription.  Given that I'm not interested in having this project be a continuous money suck (other than the 4G connection that I also use for other things), if anyone knows where I can get the data streamed for free, that would be great.  Otherwise, this feature likely won't get addressed.
UPDATE:  Real-time Box scores between half innings just added.  Read about them/see the video demo here.

    Issue #2 - Archiving of old games, disk space management to make sure it doesn't fill up.
    Discussion:  Given that each game is a couple of hundred kilobytes in size, and the SD cards are 4GB or more, running out of space is not a problem I've come across yet.  However, in heavy use, it is a potential.  Archiving the old games also allows the possibility of replaying a game through the scoreboard (by placing the game files back into the parser's input directory).  While this is not a function currently incorporated into the scoreboard, I've done it via the command line during development for testing and to show others what the board is capable of.
    Resolution:  My thoughts on fixing this would be to run a piece of code at boot time to clean-up the disk prior to the scoreboard starting.  The code could move the files from the last use into a date-time stamped folder and check how full the disk is, deleting the oldest files first until back below a set threshold.

    Issue #3 - Parser is a kludgy piece of PERL code
    Discussion:  As the focus for this project was on getting something working sooner rather than later, I decided to implement this as an interpreted script vs. compiled program.  PERL was the logical choice, as pulling data out of the stream involved a lot of regular expressions.  As it was a work-in-progress, I basically wrote what I thought I needed and then hacked on it until it worked correctly.  Given the large number of components required for this project, once it worked, I moved onto the next thing.
    Resolution:  If this were a professional project, I probably would have used the PERL script to refine  how the program should work.  Once complete, I would then look to streamline the program and reimplement using a compiled language.

    Issue #4 - Parser ignores non-gzipped data streams
    Discussion:  In my very quick analysis of all of the data streams headed to the server, only the compressed streams held what I was interested in.  However, I only looked at a few streams to make that determination, so there may be uncompressed streams that have the info I am interested in.  Given that the uncompressed streams have the same JSON structure, processing them through the program should be easily implemented.
    Resolution:  This should be relatively easy to do.  The parser would need to check to see if the particular stream is compressed.  If not compressed, the parser would just need to read the contents in (bypassing decompression), and then it's situation normal.

    Issue #5 - Lots of cool things could be pulled out of the stream and displayed given time.
    Discussion:    I'm only pulling out score, inning, balls-strikes-outs, and runners in order to populate the scoreboard.  Lots of other stuff comes across the stream that could be displayed that I'm currently disregarding (such as lineup changes, a text description of the last play, etc).
    Resolution:  The sky is the limit with this capability.  Once the desired information is located within the stream and a scheme is figured out of how to display the data, the parser just needs to be modified to output the data as desired.

Web Server


    Issue #1 - No option to run test sequence
    Discussion:  While it shouldn't be necessary under normal conditions, there have been a couple of circumstances where being able to cycle through the test sequence would have been helpful for verifying functionality.
    Resolution:  This should be as simple as adding a link to the home page that calls a script to dump "test" into command.txt (will result in the test command being sent to the Arduino).

    Issue #2 - SetLogo web page is less than optimal
    Discussion:  In order to get things up and running as quickly as possible, the SetLogo form is just a bunch of checkboxes arranged in a grid.  While it gives a rough impression of the logo to be drawn, it is hardly a great representation of the logo to be drawn.
    Resolution:  Need to research a little more, but should be doable using a CSS and javascript.

    Issue #3 - Closer integration with GameChanger to get Team ID
    Discussion:  Right now, the user has to manually visit the GameChanger website, retrieve the TeamID, and input it into the web page in order for the TeamLogo to automatically be mapped to the correct side.
    Resolution:  Will require more research, but could be doable via any of the following:  1) Intercept the initial messages containing team names and present that as a drop-down on the web page, 2) Correlate the team ID over many games to figure out who the home team is (home team ID should show up over and over ago, while the visiting team IDs should change), or 3) Figure out whether or not  real team IDs are identifiably different than the fake team IDs and use that difference as a means to identify the home team automatically.

    Issue #4 - Ability to replay old games
    Discussion:  In the past, I've often found that it was useful to reply games to demonstrate to others how the scoreboard works without having to score a fake game and/or to use for troubleshooting.
    Resolution:  This is easily done on the command line by copying the game files into the parser's input directory.  Just need to add a web page that enumerates the saved games, allows you to select one and then feed it to the parser's input directory.  As this can sometimes take a long time to play out, this should probably also include a capability to stop playback.

    Issue #5 - Web page appearance leaves much to be desired
    Discussion:  In order to get the web server up as quickly as possible, no frills were used; just a simple, straight HTML web page.  As a result, its appearance leaves much to be desired.
    Resolution:  A decent CSS paired up with some basic layout changes should fix this problem pretty handily.

    Issue #6 - Web page that changes the displayed game state would be more convenient if it populated the existing values first
    Discussion:  Right now, the web page that allows for manual game change currently starts with all zero values.  If there is only one thing that needs to be fixed, rather than enter than one thing, you end up having to enter everything on the scoreboard manually.
     Resolution:  This actually requires a bit of coding to accomplish.  First off, the parser will need to include a subroutine to write out the game state to a file in addition to sending it to the arduino.  Then, the web page will need to include code that reads in the game state to set the default values for each of the form elements.

    Issue #7 - Web API for sending score to scoreboard is not documented.
    Discussion:  While coding up the set scoreboard page, I realized that by using HTTP, you could update the scoreboard without needing GameChanger.  This could enable other programs to interact with the scoreboard easily and/or relay the score from one board to a possible second scoreboard.
    Resolution:  This is relatively easy.  Just need to dissect the elements of the scoreboard form and what values they should take along with the URL in order to derive the API.

Conclusion


    While I'm sure there are other issues with the scoreboard, these are the ones that I've personally identified as needing work.  Please let me know if you've seen others.

Up Next … All-in-one quick start guide

No comments:

Post a Comment