This thread is for technical discussions about the OSx fork of ProffieOS - usage, features, compatibilities, troubleshooting, thoughts. Especially interesting would be your thoughts on OS/OSx intermixing potential: which OSx features might be of interest to integrate in the main OS, and which of the main OS features you think OSx lacks mostly. Any feedback is good feedback.
ProffieOSx Resources:
So, correct me if I’m wrong, but you basically took proffie and somehow figured out how to make it more complicated? Or, rather, how to make it more user-friendly by making it more complicated. No?
Some interesting things in the OSx documentation:
That sounds interesting. What benefits does that have? Is that for “inhilt” setups or just accent leds?
Does this mean you’ve been able to achieve deep sleep without hardware changes to the v2.2? Or is it code specific to the hardware changes?
I too have questions, like:
@RSX ?
Colorimetric LED Driver: The site has a lot of documentation on this driver. Instead of using a lineal adjustment on two data points (max and min voltage) it uses many curves of output (lux) at different battery voltages and PWM levels to have more consistent power output (and thus, color accuracy) at different battery voltages. The main difference seems to be the G and R channel when battery drops below 3.6V and luminosity is above 80% or so.
The tradeoff is a much more complicated definition of the LED, and the need for accurate curves of data. I’m more of a NeoPixel guy, and don’t seem to remember that lineal driver is “broken”. But my guess is that it could be “ported” to ProffieOS, what I don’t see is the why.
The short answer is 8312 bytes - about 12% - and still leaves more than 40% available for dynamic allocation. Here’s Arduino’s compilation report with and without that part of code:
Global variables use 38032 bytes (58%) of dynamic memory, leaving 27504 bytes for local variables. Maximum is 65536 bytes.
Global variables use 29720 bytes (45%) of dynamic memory, leaving 35816 bytes for local variables. Maximum is 65536 bytes.
Cosmin
There’s nothing particular to our hardware that enables deep sleep, the only conditions are:
I don’t think there is any reason why Proffieboard V2 cannot support deep sleep.
Cosmin
There are two main reasons behind our rewrite of the LED driving code:
On UltraProffie we’re using the same type of low-cost, open-loop PWM driving hardware as Proffieboard, so we need some way to regulate the current while accounting for the variable battery voltage. When the battery is fully charged the voltage is too large for most LED emitters, so the excess power must be dissipated on a series resistor or the LED will burn. When the battery is almost empty the voltage is too low and it becomes difficult to get enough light from LEDs with large series resistors, for this case it would be better not to have a resistor at all. While trying to balance those two opposite requirements, we found that we can keep constant light output across a wider voltage range if we use very small series resistors, but this will aggravate non-linearities already inherent to the driving circuit, so unless we did something to correct it, we would end up with inconsistent behavior. For instance if we put a control value of 127 (out of 255) for a LED emitter, we want to get 50% of maximum light across the entire battery voltage, not 30% when the battery is almost empty and 80% when it is fully charged. To capture those non-linearities in the control software, the simple linear model that the original Proffie used for PWM regulation was not appropriate, so we’re using piecewise linear approximations instead, hence the PWL driver. In short, we’re using complicated software drivers to get maximum of performance from low-cost hardware.
We’re aiming to bring sRGB color specification to Proffie (we’re not there yet). Now the same RGB code would look significantly different on a computer screen, a pixel blade or an analog RGB LED, and this becomes a problem if one tries to specify colors using a computer. The question here is about the mixing ratios: how much red, green and blue should we display on a specific LED, to get visually the same color as on the screen? The technical solution is color space transformation, which is accomplished by a color transformation matrix and requires prior knowledge of the target LED representation under a standard color space, such as sRGB. For this reason we introduced color renderers, which can handle color transformations, gamma corrections and some artifacts for monochromatic and dual-channel blades.
For any of this to be useful, LEDs must be thoroughly characterized and consistently manufactured, so it won’t work well for DYI, hand-made blades. But the Proffie-style of LED specification is still fully supported under OSx, except it won’t achieve the above goals and it is specified in XML (then COD), not in firmware:
<Legacy_aLEDdriver BinOrder="?"> <!--! set BinOrder !-->
<EntryType BinOrder="1" Format="char" value="s"/> <!-- struct -->
<StructID BinOrder="2" Format="uint16" value="21" /> <!-- ID -->
<StructHandler BinOrder="3" Format="uint16" value="100" /> <!-- xAnalogLED_Driver_Legacy -->
<StructSize BinOrder="4" Format="uint16" value="23"/> <!-- 23 BYTES in subsequent fields -->
<MaxAmps BinOrder="5" Format="float" value="1"/>
<MaxVolts BinOrder="6" Format="float" value="2.65"/>
<P2Amps BinOrder="7" Format="float" value="0.35"/>
<P2Volts BinOrder="8" Format="float" value="2.2"/>
<R BinOrder="9" Format="float" value="0.68"/>
<Red BinOrder="10" Format="uint8" value="255"/>
<Green BinOrder="11" Format="uint8" value="0"/>
<Blue BinOrder="12" Format="uint8" value="0"/>
</Legacy_aLEDdriver>
The whole system is still underused under the current version of OSx, as there’s not yet a clear use case requiring standard color specifications. Pre-Proffie we worked with graphic styles (not coded in firmware but drawn with an image editor), a feature that we’ll eventually bring back to live, so I guess the whole colorimetric section is more in preparation for what’s to come than of immediate utility.
Marius.
The controller flash isn’t updated directly from serial, we use the serial to transfer files to the storage (SD) - in the case of firmware update we copy a COD file (a wrapped BIN) and on reboot the firmware loads the update file.
For the serial protocol we use 2 modes - the classic ASCII communication and a binary mode; for the ASCII communication we connect to the serial at a low speed (9600) but for the binary communication we connect at baud 921600 (the highest speed we tested which worked with most of UART to USB adaptors). We switch in between them as needed, usually keeping the connection in ASCII mode and switching to binary mode only to read/write files (with available commands like open file, read/write from file, close, delete … etc; specifics will be published in Binary commands wiki).
Regarding robustness - we’ll cover this in detail in the wiki for Binary Command - until we update the wiki and to keep it short: each command is wrapped in a protocol layer with a few security features:
each command sent to the board receives a response
each command sent and it’s response has a specific id, size, content and CRC32 at the end
and, of course, error flags for the protocol and specific per command
I gather the same protocol can be used for bluetooth communication.
Besides the communication reliability for bluetooth the next issue would be speed. For configuration files and even firmware I don’t think it will be a problem but for sounds it might be - we need to do some testing. To give you an idea of current speed via serial connected at 921600 to transfer a font of ~10MB to the SD it takes around 4.5 minutes. On bluetooth this will vary with the module (protocol, speed), distance, position inside saber.
Andrei
sRGB is a limit color specification which cannot accurately show deep blue and deep red colors.
True, but that’s how most computers represent color.
Marius.
I suppose we could add an sRGB<> style template which would convert the values to the internal representation, which is 16-bit-per-channel linear. For actual color accuracy we would need to decide what primaries the internal representation is in though. Like, maybe we could use the Rec2020 primaries, which is wide enough to include most deep colors.
To be frank, any color is going to have to go through either a foam and an opaque plastic (neopixel) or through foam and/or many layers of film, plus a transparent plastic. Oh! And the plastic width and the diameter of the internal diameter is variable, too (you know, thin and thick blades, with 1" and 7/8" nominal diameters). And for cree and tri-cree you also have to consider blade length and whether it has a mirrored blade tip or not! Trying to get deep color accuracy when the output such ridiculously variable is not really needed. I think that just making color consistent through battery voltage variance is more than enough.
May be is my background in DTP, with color probes and Pantone guides for actual color reproducibility, but putting so much effort when the final product is so variable, seems counterproductive.
I wasn’t thinking about going with this so far as to represent deep colors, the main goal was to get color consistency across different blades and computer screens, but in theory yes, we could adopt any color space, including wide gamuts such as Rec2020.
Marius.
That would indeed be a problem if only the light source would be characterized, but for colorimetry we’re normally measuring the complete blade, not just the LED, so most of the variables you mentioned (plastic, foam, film, etc.) are already accounted for. Light uniformity across the blade is still going to be an issue for in-hilt analog LEDs, but that’s not something we could solve in software anyway so I’m just aiming for “close enough”, not for “perfect”.
Marius.
We recently updated our power manager and on this occasion we ported it to the main OS and made some measurements on ProffieBoard v2. We got 0.5 mA in deep sleep, with this it should take months to drain a good battery.
We launched a pull request on the v7 branch of the main OS. The code is documented here: Power Manager · RSX-Engineering/ProffieOSx Wiki · GitHub
Marius.
That sounds excellent, but all pull requests should be made against the master branch.
From there I will cherry-pick bugfixes onto the 7.x branch as needed.
@RSX i recently bought a ProffieOSx equipped saber and was just curious if there were any plans to include gesture control based activation like twist to ignite. is that something like that in the works or would that interfere with the deep sleep mode you mentioned earlier?
Believe it or not, this is something we are currently working on. It does indeed interfere with deep sleep, but it seems there’s a way around it. No promises at this time, haven’t got to testing this yet, just letting you know we’re looking into it…
Marius.
Oh awesome! Im looking forward to seeing what you guys come up with.