Crystal Focus X (v10) specs, demo and discussion

[erv]

Please Welcome the Crystal Focus(tm) V10 (CF-X)


(Pictures of the board pre-series, machine-assembled and produced at home. Minor labelling and silk-screening changes on the final version)



yes, it took a while :-)
If you are a newcomer to this, you might first have a read to this thread, details and dev. backstories, and discussion, about the CF-X :
Crystal Focus X and some news from the Plecter house

Here's a PDF version of what's below, I though it might be great to have it to share aside of the forums and avoids tons of copy/paste.
CF-X release notes / specs PDF
https://www.plecterlabs.com/Media/Doc/CrystalFocusX-Specsheet.pdf

Feature list (non-exhaustive)
•   ARM32 based board with 3.2W digital amplifier (constant power / volume over runtime), with 128x32 OLED support, 4 channel (RGBW) on-board drivers, USB serial port, SD card, activator + auxiliary switch, 9DoF motion sensor with MotionFusion, on-board (red) diag LED, temperature measurement and alert, voltage measurement and alert (PLI).
•   We use / kept as many as the former CF components, strong and reliable, easy and cheap to replace / service, less manufacturing issues, we try to avoid 0402 or smaller active parts which make them impossible to service by DIYers and would even make it even really hard for us (since we repair customer boards when drama happen), plus they increase / introduce manufacturing errors.
•   Dimensions: 34.30 x 20.75 mm. Black and gold PCB
•   SD card update with signed firmware. “Blind update” possible (on-going flashing process with the onboard diag LED) or with USB serial port monitoring (recommended). A firmware update takes about 1s or less.   
•   SD card in place sound editing / replacement
•   1 / 2 cell compatibility with no “voltage-hack” required, only a solder jumper to bridge, and only when using ledstrips with 2 cells (+5V buck regulation needed then for the strip)
•   Auxiliary serial port (like the former RICE / TTL serial port). Fixed and Auxiliary 3.3V power supplies
•   3 additional GPIOs (1 currently used for Tangible interaction / blade detection)
•   HB led or Ledstrip compatible (RGB / RGBW)
•   Enhanced accent sequencer with 8 configurable accent LEDs (blade mirror, even in ledstrip mode, crystal pulsing, scalable PLI, sequenced accents, self-pulsing, audio flicker)
•   8 Accents resistors footprints (0603) allowing for top or bottom on-board bargraph (board can be installed facing up or down)
•   Zero CPU Ledstrip driver with 2 outputs, with level shifters (compatible with 1 cell or 2 cell setups, or permanent +5V PSU for booth/demo mode).
•   SD card benchmarking routine ported from CF9 and made accessible via remote message / hook (formerly a dev tool)
•   16 bits / 44.1 kHz sample rate multi-track, low latency motion to sound (4.6 to 6ms motion to clash sound) with backward compatibility with 22.050 kHz sounds (monophonic font main player should have at least hum and Fx with the same SR, otherwise, non-mixed sounds can mix SR)
•   Polyphonic / monophonic font (backward) compatibility with existing fonts. Unlimited file numbers or font numbers.
•   Automatic font number detection and diagnostic – Ordered Font names
•   100 ms boot time average with 12-15 fonts on the SD card
•   Enhanced logging / debugging mode of all events of the board
•   Omnisabers ready (like CF8-9)
•   Software hooks to remotely control any aspect of the board (power on, power off, lockup, clash, blaster, on-the-fly font change, tracks playback etc) via the serial port(s) or external events (tangible, force sensing, user identification)
•   Extended tangible interaction with 16 slots including blade detection (saber enabled, disable, blade insertion / removal interaction)
•   AccuBolt / Multibolts engine
•   16 Color profiles and 16 blade profiles allowing mix and match, selection via Spectrum™ (angular) selection
•   10 bit color definition for more color accuracy in HB leds (and future ledstrips !) – [Legacy]
•   Color dictionary to name (web) colors
•   Hilt roll (twist) controlled lockup color (FoC / Lockup color blending). Think Qui-gon Ep 1 & Blast door.
•   Extended use of User Interface (UI) sounds and graphics. Fully skin-able.
•   SmoothSwing, implemented as described by Thexter with his public documentation, with a bunch of tweaks and heuristics to get it to my taste. Smoothswing font automatically detected, 3 Smoothswing mode legacy SS, hybrid font (using swings sounds) and (pseudo) pitch shifting mode. Per-font Smooth-swing configuration (doh)
•   Vocal menu for font selection, iSaber and (soon) parameters adjustment, with use of the OLED display (if attached), animated or static graphical font description.
•   Local tracks and iSaber tracks [description further] audio player(s) and double click play/pause
•   Sleep mode (accent stop, partially reduced current) with automatic wake (aux, movement) - Deep sleep with 240uA (18 months of shelf-time with a 3200 mAh fully charged cell). Board revived with either AUX or ACT
•   Support for NO and NC latching switch though some of the new features require ACT as momentary switch
•   Motion sensing for font selection (in menu or when blade is off)
•   Quick Ignite: automatically starts the saber when reviving from deep sleep (en./dis.)
•   Power-on sound interrupt with motion sounds (en. / dis.)
•   OLED Font graphic support (static or animated), or font name and number if no graphic provided.
•   OLED animation diversity (signal analysis, vu-meter, screenAccents™, midi-chlorian scanner)
•   OLED animated screen savers (currently 4), can be customized to taste.
•   OLED 3D files support (custom spinning 3D object on the screen, OBJ file format)
•   OLED PLI support (custom, examples provided)
•   OLED orientation parameter and custom boot / info strings.
•   OLED custom boot screen (static or scrolling) or font graphic
•   OLED animated blade and color profiles transition
•   OLED animated blade insertion, removal, tangible selection, saber disabling or low power
•   Reduced idle quiescent current: 42mA with SD card and all peripheral activated (not playing sound)
•   High temperature, low power, dead power, blade missing, blade inserted UI sounds & graphics.
•   Disable lockup and blaster for heavy duelers (Use 0 for lockup delay)
•   Font skipping for quicker selection in the vocal menu (when the SD card stores 1138 fonts but you don’t need all of them)
•   Spectrum™ “filtered” selection (per font) to reduce the selection to a limited number of color or blade profiles
•   Booth Mode (or mannequin / poser) with automatic ignition retraction with randomized blade & color profiles
•   Magic activation and saber locking / unlocking using a magnet
•   Easter eggs!
•   75€ price point (retail). Bulkers welcome. Price to evolve if quantities / bulks evolve.

[Configuration system]
We kept a big part of the former configuration system but mostly reorganized and split it (most of the parameters keywords you knew were preserved). The configuration is made essentially of 3 files:
•   A general config.txt file in the root directory. It contains all the general settings, motion sensing, sleep / deep sleep delay, volume etc. In addition, it contains up to 16 blade profiles which are the specific settings which used to be stored “per font”. Instead of limiting the use of specific settings (flicker speed / depth, pulsing, ledstrip effect etc) to that particular font it becomes part to a more general vocabulary, accessible to all fonts, and changeable in real-time
•   To this vocabulary we add a separate glossary of colors (formerly the color profiles that were in override.txt) and store them in a specific color.txt. That file contains up to 16 color profiles that have all the color aspects separated from the blade profiles: blade & FoC color, bolt color, lockup color, FoC mixing, trident channels, crystal chamber color. Same as for the blade profiles, those are accessible to any fonts, and changeable via Spectrum™ just like the blade profiles.
•   A font specific configuration file (font_config.txt) which now contains only the parameters that are specific to that font. That includes (mostly) the smoothswing settings (if it’s a smoothswing font), the bolt timing settings, font skipping in the menu, color and blade profile filtered selection, font glyph)
•   In addition, you’ll find the former prefs.txt file that saves the last use of the saber (blade & color profiles used, last font used etc) and a special.txt file storing manual override or very specific parameters that you want to add / edit by hand. This is typically where you’d store some of the OLED preferences, enable tangible font selection, activate the booth mode etc.

Timings & units:
Former HW allowed for a 2ms time base only hence the timings used to be defined in that unit. The new HW runs obviously faster and allows for a finer time base, now everything is metric: 1ms. Voltages (PLI) are stored in millivolts.
We also made a notable change with the bitfield notation we were using: defining FoC mixing was done previous with a natural binary representation, i.e. with the most significant bit being the left-most one. This goes against the natural numbering of the channel orders (e.g. for color definition, ch1, ch2, ch3 & ch4), so now the bitfields (FoC mixing, Trident delayed channels, accent leds states) are defined in natural order (my brain is now having a really hard time with this since it’s been hard wired for binary stuff for a long time but I’ll deal with it  )

Accent Sequencer
The new accent sequencer gives more flexibility on the use of each accent. Also, we merged all the different led files into a single one with proper sections (single leds.txt file) stored in the font folder.
Here are the various attributes each accent can have. To be noted that pulsing type of accents (self-pulsing, crystal pulsing, blade mirror, audio flicker limited to accents #2-5-6-7-8 since not all the HW pins can have PWM. You can *still* define non-PWM pins to those function but they will only blink like a digital pin when passing half of the PWM range (512).
•   1, 2, 3 or 4: defines a mirroring, whatever the order is. This ways, accent #5 could mirror channel 1 or 4 (applies to current color profile, real time color changing leads to real time update of the accent mirroring; obvious but…). Blade mirroring on those accents works also while in pixel blade mode.
•   p: accent is used for PLI
•   @: accent is used for audio flicker (flickers on the audio beat)
•   a: accent is used as regular sequenced accent
•   r: accent is used as random sequenced accent
•   ~: accent is pulsing on its own (between max and max - depth)
•   O (letter upper case O): accent is static ON when the blade is ON
•   o (letter lower case o): accent is static ON when not in deep sleep (identical to wiring it to the DS pad but configurable)
•   C: Pulses between CRYSTAL chamber COLOR[CHANNEL1] and depth (current color profile)
•   R: Pulses between CRYSTAL chamber COLOR[CHANNEL2] and depth (current color profile)
•   Y: Pulses between CRYSTAL chamber COLOR[CHANNEL3] and depth (current color profile)
•   S: Pulses between CRYSTAL chamber COLOR[CHANNEL4] and depth (current color profile)

The PLI is fully scalable and can take any LED, even non-contiguous ones. For instances, declaring accent 1, 4 and 5 as PLI accents will map the PLI range to those 3 leds (#1 being always the low end of the PLI, which blinks when you reach it).
The sequencer has now a simplified syntax and structure. It accepts repeat blocks and infinite loop blocks. A sequence (idle for instance, when blade is off) can be introduced with a repeat type of block with a particular pattern, followed by an infinite looped sequence. A block can have 32 stages and a sequence (blade on, blade off aka. Idle or lockup) can have a maximum of 16 blocks. We thought that 512 stages for an accent sequence is, if not slightly overkill, “enough & fair” for the least.
Blade ignition and retraction accent schemes are now part of the single leds.txt file in specific sections and can also have their own sequence, progression pace in the sequence being either manual (delays specified) or automatically computed based on the power-on sound duration or the quick-on parameter.
To simplify the accent animation writing / authoring, you don’t need to enter the stage duration for each stage anymore. If you plan a constant speed sequencing, just type the delay used at the beginning of the sequence and the whole sequence will use it. You can do partial updates as well, define one delay, use it for a couple of stages, update it, have a few more stages with that different pace etc.
Regarding accent types and priority: any specific mode has priority over the regular sequenced LEDs (‘a’). In other words, the state of a LED, even if defined in the sequence will be overridden by the PLI or the pulse or the blade mirror (etc) if the said LED is not a defined as a regular accent.

[splitting this over several posts]

[erv]

Comments / notes
The configuration files support both C++ “//” comments and Emacs (or script) “##” comments at the beginning of a line to disable it. To make testing easier, we also implemented C block comments with “/*” to start a block and */ to end it.  Pretty handy for leaving various versions of a parameter set in a file before deciding which one to keep. It remains recommended to reduce comments at the end to limit the parsing (hence the boot) time but the MCU is fast enough to regardless deal with it.

Font naming and numbering
With a (now) full handling of the SD card file system, thanks to the faster MCU, sound banks can be named with the font name to have a more readable SD card structure. The font order is just defined by a leading number followed by a dash or underscore and that’s the only mandatory part of the naming, along with a proper contiguous ordering (no gaps in bank numbers).
There is no limit regarding the font numbers aside the SD card size and the expected / acceptable boot duration. That being said, fonts scanning is extremely fast and limited to the raw analysis of the root directory to find how many fonts are available so the impact on the boot time is limited. I tested a silly package with 64 fonts and it took 320 ms to scan, which remains acceptable IMO for such an amount of data stored. Since browsing such a font thesaurus in the vocal menu, fonts can be defined as “skipped” in the font_config.txt to make a short list selection for the fonts you want to enable at a time.
(check the PDF to see how the SD card folder looks like)

Local tracks and iSaber audio player
It’s been a reminiscent request that could hardly be done with the previous hardware, so I totally rewrote iSaber and merged it along with the saber app and made it contextual. We wanted to keep iSaber as a “special” audio player mode (think saber = portable player / MP3 player) along with some of the features people loved about it, like the audio bargraph on the accent LEDs, pulsing on the music. At the same time, users want to experience a full saber scenario (smoothswing, motion fx, ignition, retraction, blasters) while playing a back track (which isn’t new obviously).
As a result, we made the track player contextual to the font. If a /tracks folder is present in the font itself, it will automatically make the tracks available for playback using the activator double click as play/pause control, and long press to fetch the next track. If the local tracks folder isn’t there, the double click is automatically disabled.
The iSaber mode remains available from the vocal menu. Once selected it will use the latest used sound bank and will use this time the specific audio tracks stored in the former /tracks folder of the SD card (from the root dir, not within the font). In addition, it will use the bargraph as loudness level pulsing on the music beat like it used to be. Auxiliary switch use is preserved for the saber scenario, which remains fully accessible either in local tracks or iSaber tracks playback.
That split between local and iSaber tracks allows for having a specific playlist of tracks related to a specific font as well (d’oh) and have a narrative approach of the font with that audio contents (track playback to evolve soon with story playback). Conversely the /tracks folder offers in iSaber mode a totally different playlist that can be used with the blade off and some non-props related music.

Omnisabers
The Omnisaber v2 code is finalized and I’m going to make a small run of those during the summer. It communicates over Wifi and talks to a computer app with a sampler to play the sounds for live performance shows, with low latency and using Open Sound Control, like the devices I’ve been developing for my day job since the early 2000’s (Ethersense, WiSe Box). The board embeds a webserver available at all time for tuning parameters. When setting up the wifi connection, the module is set to Access Point mode to log to it with the computer or a smartphone and can be configured in the Web browser. It also features Alexa hooks allowing for vocally controlling the saber when at home (via internet) and can be controlled by your Home Automation System locally, such as Domoticz (without using the internet)


Availability
Manufacturing is on-going in the USA and in the EU. We hope to have the first batches out for early august.

Road Map
I’ll take a short summer break from the 8th of July to the 16th then I’ll come back to code to continue working on the road map. In the meanwhile, we’re manufacturing boards (USA and EU). I’ll probably push several updates of the FW during or short after the board release, as I have a lot of things I want to keep adding, and now the code structure and hooks are ready, it’s just a matter of adding scenario levels and layers. The default package will keep evolving quickly too. Some of the fonts in the default package have been already updated with smoothswing by their maker, others are in progress. (Betas and nightbuilds will be available on my website in the dedicated section)

To come (July, August)
•   User’s Manual (!). It’s not like I have a full rewrite to do but it’s a lot of work. I’ll publish updates of the document along the road, a draft to be published asap so that wiring and basic config is detailed to users.
•   Combos (pushed back as it’s was a “priority” feature to re-enable in the code)
•   Storyline telling mode (font based)
•   USB mass storage access to the SD card (structure is there, not finalized, but on the top of the TODO list)
•   Secondary accent sequencer with pixel rendering (secondary ledstrip output)
•   More ledstrip fx and options, now easy with the new code hooks and callbacks.
•   More motion / position selector. The computation, logic and glue are there, just not applied yet (stabs will be the first thing to benefits from this)
•   Full blown vocal menu. All the options are ready, but the Menu (C++) class is still WIP, I didn’t want to break the menu close to a release date, so more Beta stuff to come later during the summer.
•   RICE (!): I need to work on it, no time for this so. The (strong) base is there (CF9+PZ 5.5 RICE), I just need to sit down and work specifically on this (been busy with the code base, demos and my saber). Also, once I work on this, I’ll re-forge all the existing RICE for the recent boards so that their work on the recent macOS (their new file system broke compatibility with the older apps)
•   The ASCII art player over the serial port (playstarwars) needs more work to reduce frame flickering, not sure the port is fast enough to do that anyways but I’ll try to improve it. Not that it’s a fundamental thing (lol) I just love it.
•   Blade PLI (ledstrip)
•   Some sound work as I know I can improve my sound mixer for faster mixing and some better layering of the code
•   Multiple hum, lockup and “other” sounds. Nothing specially complicated or new, just making the stock font capability increasing
•   Tangible interaction will keep extending

To come (later)
•   Android app: I recruited a developer to keep working on this, he’s highly excited about the project. That will take time though (just like me he has a day job) but it’s on wheels.
•   More color tuning



First demo
I posted that a few days ago on FB, reposting a proper edited video here. Legacy feature "magic activation", enhanced.

[erv]

A demo of the ledstrip stuff, including Spectrum(tm) color and blade profile selection, new fire color mapping, and smoothswing.

[erv]

Now before going into some of the board details, a few things I've been working on, this one with Omnisabers and home automation 

[erv]

Some review of the features. Interaction scenario with the UI sounds and graphics, the OLED display, blade detection & removal, screen savers and all the stuff you can "skin". Pretty much *nothing* is set in stone in the FW, sound and graphic resources (UI, theme, interaction) are stored on the SD card.

[erv]

Now some of the remote control aspects of the board, as well as PLI and skinning. The PLI, like the rest of the resources, has its own graphics and configuration coming from the SD card, easy to edit and change (variants provided with the default package, all it takes is renaming the file you want to use)

[erv]

Another thing I've been researching on, Savi's workshop at Galaxy Edge being the trigger but not only. 7 years ago I make my home cinema room controlled by a HAL9000 unit and RFID
HAL 9000 working Panel - Demo 2 - YouTube

I wanted to experiment this with saber, the goal being to get more tangible interaction systems, and possibly wireless. So here's wireless identification, with glowing LED thanks to NFC support added to the CF-X. As mentioned in the video it's a custom companion board and a self-wound tuned antenna. (I yet have to make it smaller but it isn't bad for a prototype). I initially started with 125 kHz RFID scanned and parsed by the CF-X itself (yes, real time demodulation). It worked but those old RFID need a beeffer and bigger coil, so I decided to go NFC, which is also matching more "nowadays"

User identification is one of the obvious use in our saber scenario, as well as saber locking, unlocking or activation but also font change (tangible font or config selection) ! Glowing led with proximity as a bonus, we foresee lit crystals with those, maybe Darth Chasm can tackle this (I saw his resin cast crystals with LEDs)

[erv]

Bonuses and Easter Eggs !
Special props to my young friend Enzo who actively collaborated on the CFx Extra's spending hours on the small graphics and proposing and coding some of the extended / bonus for the OLED !
It's fully described in the default package of the board (that I yet have to post on my website) but if you wonder "why" about this... the main answer is why not ! There is also a backstory from my time at the electronic engineering school, we had Agilent oscilloscopes with such easter eggs and I promised myself I will add some to my electronics, one day  Now it's done !
For now the games are accessible only via serial commands, but once we get the full menu finished, there will be a specific access there to launch them. Not a reason to not demo them ! 

[erv]

stay tuned ! 15 minutes to go for youtube !

[Yaraell_Ren]

Just watched the Smoothswing demo. And WOW it is amazing!
This is by far the most powerful saber board :)

[Darth Chasm]

...maybe Darth Chasm can tackle this (I saw his resin cast crystals with LEDs)

 

[Yoda]

Excellent stuff going on here Erv

So it looks like it can toast the bread and butter it at the same time

Not to mention we can play old Atari games on it now as well 

Definitely looking forward to using this and utilizing some of the new Accent LED configurations
to go with the Blade set-ups.

I really like the temperature monitoring feature  as with so many hilts and chassis out there
that barely have any room for the electronics to breath / vent the heat... this will be helpful


I am wondering... if because the board size is small enough to be fit sideways in some hilts do
you think adding a "board orientation" designation for the accelerometer to determine if X,Y,Z
is facing top bottom or side would be useful to implement now that there is the smooth swing
and enhanced twist/rotational detection? (food for thought)


The Layout looks good as well, the only problem I see is it doesn't wire and install its self
but still, Simply Marvelous 


MTFBWY
always
YODA

[erv]

The Layout looks good as well, the only problem I see is it doesn't wire and install its self

On it Sir !! along with teleporting ! some dev delay could occur 

[Yoda]

The Layout looks good as well, the only problem I see is it doesn't wire and install its self

On it Sir !! along with teleporting ! some dev delay could occur 

Ahhh well don't want to keep people waiting so maybe we can wire them ourselves


What are your thoughts on the accelermometer/board orientation / direction in the hilt suggestion?
Maybe something as simple as horizontal or vertical orientation so that motion and twist don't get
mixed up depending on how the board gets installed inline or sideways in the hilt?

If its not a practical feature or will mess with existing parameters don't worry as sideways
won't fit most narrow hilts but could be an option later on?

[Machinimax]

I don't want this....I NEEEEDDDDDD IIIIIIIIIIIITTTTTT!!!!!!!!!!