AXIOM Remote/Hardware

1 Printed Circuit Boards

1.1 PCB Version 0.9

The first development prototype of the AXIOM Remote printed circuit board (V0.9) has been designed and routed, ordered, received and populated. This first version is not meant to be perfect (for testing we just used a simple 6x6mm Alps push-button type - not the more expensive ones with better haptic feedback) but should provide a good foundation for developers to focus on ensuring that the menus work and how to create an intuitive and pleasant user experience when operating an AXIOM camera.

PCB Source files: [1]

1.2 Version 2 Prototype

Plans/Considerations:

Remove Second Knob (For menu navigation and the changing of parameters so far we found no use for it designing the UI).
In the future we may add flash memory for storing of images - for version 2 we left it out. So far we have not exceeded the PIC32MZs internal storage memory but if we want to make the internal help system more extensive with lots of added illustrations/images it might be required to add more flash storage. Routing looks challenging for a 2 layer PCB... consider dropping it again for now.
Remove left side rocker switches. So far we have not found any function for them. They are prone to being switched accidentally as they stand out from the device quite far. Having buttons/switches on the left side of the remote prevents it from being attached to the camera/rig on that side.
Remove top side pushbuttons. So far we have not found a real application for them. In line with good user interface design / user experience these buttons need labels so the user clearly sees what is going to happen when he presses them. This is difficult as the label would not be visible from the front of the device.
Reduce number of RGB LEDs to two (for status LEDs: State and Operation). So far we have not discovered any real world benefit to having RGB LEDs to illuminate pushbuttons. Changing the button illumination color to indicate something happening while pushing it makes little sense as while pushing it the users finger is covering the button making it impossible for the user to see it.
Having one white LED per pushbutton could make sense that as it could indicate which buttons are currently active (requires buttons to show significant transparent surface so the light can shine through). We will see if we have enough lanes/space for that or revert to using one white LED for multiple buttons illumination.
add 4 more holes to PCB somewhere close to eachs PCBs corners so the enclosure back can be screwed together with the enclosure front.
rounded corners for PCB so it fits into enclosure better, 5mm radius
to save space some cutouts on the PCB would be handy for adding thread mount points to the enclosure in the middle of each side
shall we add additional PCB screw holes near the push buttons to add additional stability and prevent the PCB from being bent by force being applied to push buttons. Screw holes take away quite a big amount of routing space so the goal is rather to add support pillars without screws from the enclosure back where the pcb could be prone to bending due to buttons being pushed.
replace slide switches for ON/OFF and LOCK with pushbuttons
button placement CAD drawing:

Enclosure Work in Progress CAD Design: https://cad.onshape.com/documents/c262bd3781a0411f2fb2534f/w/95b98f509977c25c8ca274bf/e/f19875625fa26f1f2d21ef19

2 Electronic Components

Core Processor: A PIC32MZ was chosen. Two additional smaller PIC16 are used for handling push button, rotary encoder and LED IO.

Display: A 2.8" 320x240 TFT from Adafruit ([2]) which is pin compatible with https://www.buydisplay.com/default/serial-spi-2-8-tft-lcd-module-display-320x240-optional-touch-screen was chosen.

Higher resolution and more complex device like iphone 4 replacement display (326 PPI 3.5" 960×640 px) or http://www.ebay.com/itm/OEM-HTC-Droid-DNA-ADR6435-Original-LCD-Screen-Display-Repair-Replacement-Parts-/350711245261 smaller bezel )(documentation through: https://hackaday.io/project/364-mipi-dsi-display-shieldhdmi-adapter) were considered but not used to reduce complexity.

3D accelerometer to measure device orientation was considered but not implemented - there is really only one orientation that the Remote is designed for.

AXIOM Remote is currently powered externally via 5V DC supply (internal batteries might be considered for the future: 4x AA battery tray -> cumbersome - lithium ion battery pack that is integrated into the remote and is automatically charged through 5V/camera would be preferred)

currently the firmware is programmed with a PICkit2 directly into the PIC32MZ flash memory - in the future this shall be done over USB - having a separate microSD card containing the devices firmware is not planned.

The AXIOM Remote has no requirement for internal RTC (plus button cell battery) - instead timecode is synced with/by a connected AXIOM Beta.

Buttons/Rotary Encoders/Connectors:

ALPS SRBE210200 rotary + push switch

alternative:

https://octopart.com/en12-hn22af18-bi+technologies-7730374

SMT type rotary encoders:

http://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC05E/EC05E_list.html http://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC10E/EC10E_list.html

Beta connectivity through Hirose HR10A-7P-4S (a bit expensive but massive)

or alternatively 4 pin 2.5 or 3.5mm audio cables:

plus metal receptor on Beta and Remote:

https://www.amazon.de/sourcingmap-Kopfh%C3%B6rer-Interieur-Montage-Steckdose/dp/B014XJ1SN6

RS232C as Beta <-> Remote protocol4

Toogle Switches APEM ZL series