doomsquadairsoft / d3vice-controlpoint-xbee Goto Github PK

No wiring required! Just some code.

https://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/

The PCB has no spot on the acrylic skeleton. The PCB flops around

The panel is not nice. It is too thick, too large, and does not fit in the box.

The controlpoint should be able to do the following--

• Announce itself to the network
• Resume gameplay gracefully after unexpected reboot
• Sync state with feathers server

D3vice hardware needs Russell's seal of approval. (seek negative feedback, fix issue, repeat until no negative feedback remains)

D3vice hardware needs Brandon seal of approval. (seek negative feedback, fix issue, repeat until no negative feedback remains)

I don't know a good solution yet, but LightStrip::show() is not very good at displaying values above the maximum number of neopixels. Perhaps when displaying values above the max number of neopixels, it could switch to a binary display?

As it is right now with 16 neopixels, once the number to be displayed goes beyond 15, the neopixel display just goes blank, until the user increments the config to 255. Once 255 is reached, one more increment wraps around to 0, at which point the first neopixel is displayed. Binary seems nice for developers, but then again it's not nice to stare into neopixels and calculate what the displayed value actually is. Also most end users probably can't read binary.

Best UX is through the GUI of course, but there has to be a better way to communicate to the user what value they have chosen. Maybe a generic progress bar that means max is 255? That seems error prone. Binary still seems best.

The power supply flops around given slack in the power wiring. The main board does not stay put with Velcro. A better solution for mounting the modules to the inside of the box is preferred.

Please phase out U.FL connectors because they have a tendency to become disconnected!

Will the 2 18650 batteries drive the unit all day long?

The power supply should not have an adjustment screw. Moving parts are prone to failure from vibration, bumps, etc.

they get hot. A larger battery #11 would allow a fan

The XBee is getting so hot that the Arduino sketch crashes and restarts.

I'm thinking this is a PCB issue, but it also could have been a problem from before, not sure.

https://youtu.be/A0jY4YS_W3g

The controlpoint receives HEX encoded data generated by the gateway--

            xbee.remoteTransmit({
                destinationId: device.did,
                broadcast: false,
                data: `DCXST
                       CT${device.controllingTeam.toString(16)}
                       RP${device.redProgress.toString(16)}
                       BP${device.bluProgress.toString(16)}` // Tell DCX to act GAME 0
            })

This is nasty code that currently "parses" the received data

      if (
        rx.getData(0) == 'D' &&
        rx.getData(1) == 'C' &&
        rx.getData(2) == 'X' &&
        rx.getData(3) == 'S' &&
        rx.getData(4) == 'T' 
      )
      {
        // we're getting a state update (ST)
        
        if (rx.getData(5) == 'C' &&
            rx.getData(6) == 'T'
        )
        {
          // Controlling Team
          if (rx.getData(7) < 5) {
            controllingTeam = rx.getData(7);
          }
        }

        if (rx.getData(8) == 'R' &&
            rx.getData(9) == 'P'
        )
        {
          if (rx.getData(10) < 101) {
            redProgress = rx.getData(10);
          }
        }

        if (rx.getData(11) == 'B' &&
            rx.getData(12) == 'P'
        )
        {
          if (rx.getData(13) < 101) {
            bluProgress = rx.getData(11);
          }
        }
      }

You can see it is not flexible. For example, BP must always come after RP.

This is ideal code, but I'm unsure of how to implement a parser class.

    DCXParser dcxParser = DCXParser(rx);

      // interpret the state updates
     if (dcxParser.getDataType() == STATE_UPDATE) {
       controllingTeam = dcxParser.getData(CONTROLLING_TEAM);
       redProgress = dcxParser.getData(RED_PROGRESS);
       bluProgress = dcxParser.getData(BLU_PROGRESS);
     }

The antenna mount is undecided. The U.FL connector flops around in the case