I'm playing around with designing a somewhat minimalist controller using just an ESP8266-01, a regulator, a transistor and a few passive components. My intent is to force it into a small floral tube from Amazon, requiring the ESP8266 be soldered to the PCBA. The thing that is different about this is that the pixel data is stored on the controller in the program memory of the ESP. Since there isn't enough memory in even the 4MB version of the ESP8266-01 to store raw pixel data (i.e. 3 bytes for each pixel for each update interval) for a decent number of pixels for a decent length show, I'm instead storing segment control data in the program memory, each segment data consisting a definition of a region on the string/strip, effects for all of the pixels in that segment (such as clear all pixels, set all pixels to a certain color, dim the pixels in that region, etc) as well as counter information that determines the pace of changes to that segment and the length of time that the segment would exist. At the moment I'm limiting each controller to supporting up to 250 pixels, with a fixed 25 mS (40 Hz) refresh rate. I don't think that any of the current sequencing programs support anything close to the pixel control format that I'm using, so I'll either have to do a lot of manual formatting, or write my own small sequencer program. Oh well, something to keep me busy next year.
Minimalist Controller
- Thread starter P. Short
- Start date
Interesting. The only thing I'd add, if it was my design, was a buck regulator to drop my distributed 36V to 5V for the controller and pixels. But I suppose the limitation is not only how many pixels you can store, but what the buck is capable of, if they would match at least. But then the design physically grows to support it. But I'm interested to see where this goes.
jchuchla
Supporting Member
Is your sequence format more like calling macros for internal programs, or more like parametric descriptions of effects?
You might be able to work with vixen's tim format and perhaps a subset of the effects. The tim files are just xml files that contain the data for the high level effects. Then write a translator utility to translate the verbose xml to something more compact for your controller's memory space. Effects like set level, pulse, chase, alternate sound like good candidates. That way you wouldn't need to go thru the work of writing a sequencer.
You might be able to work with vixen's tim format and perhaps a subset of the effects. The tim files are just xml files that contain the data for the high level effects. Then write a translator utility to translate the verbose xml to something more compact for your controller's memory space. Effects like set level, pulse, chase, alternate sound like good candidates. That way you wouldn't need to go thru the work of writing a sequencer.
The latter, if I'm understanding you correctly.
Each segment in the current design consists of the following (all subject to change, of course):
1 Byte for the number of pixels in this segment (and it's clones)
3 Bytes per timer (timer preset, timer counter, and offset of another segment to activate when the counter times out), there might be several timers per segment (e.g. one for duration of each step, one for the number of steps)
1-4 bytes for each 'effect' to be applied to the pixels within the scope of this segment (examples: clear all pixels, set all pixels to a specific value, perform other arithmetic/logic functions on each pixel)
1 byte per copy (clone) of the segment (starting offset of the starting pixel of each clone within it's parent segment)
A list of child segments of the current segment and each of it's clones
There is a top-level segment that spans the entire string/strip, with child segments that control specific parts of that top-level segment (and some of those child segments have their own children, turtles all the way down).
Where can I find a specification of the tim format (although I suppose that I should go searching myself)?
Last edited:
jchuchla
Supporting Member
I don't think it'd be as clean of a conversion as I was hoping. Vixen effects don't store information about the target elements (pixels/channels) It applies its parameters to whatever group it's applied to at runtime. in other words, there's no "number of pixels" stored in the effect. It determines that on the fly.
There isn't a fixed specification for the tim format. It's simply an XML serialized version of the objects created by the effects. So if an effect has a color and intensity field, then that's what's in the tim file for that kind of effect. If the effect has 20 fields to determine its configuration, then there's 20 fields of data stored. Every effect is different.
There isn't a fixed specification for the tim format. It's simply an XML serialized version of the objects created by the effects. So if an effect has a color and intensity field, then that's what's in the tim file for that kind of effect. If the effect has 20 fields to determine its configuration, then there's 20 fields of data stored. Every effect is different.
I'd still like to look at the tim file format. I've coded to the data format that I described, but it's not a lot of code and I'd like to see how hard it would be to change the interpreter in the ESP to make sequencing a lot easier, and possibly make the design more useful to others.
Incidently, my objectives for the controller are:
1) physically small using through-hole parts
2) avoiding connectors with metal-to-metal connections
3) have all sequence data stored on the controller
4) synchronization and sequence download over the air, with WiFi is the choice over nRF24L01 due to decreased development effort.
1) physically small using through-hole parts
2) avoiding connectors with metal-to-metal connections
3) have all sequence data stored on the controller
4) synchronization and sequence download over the air, with WiFi is the choice over nRF24L01 due to decreased development effort.
jchuchla
Supporting Member
Here's a sample.View attachment sample.tim
I just created a simple sequence with one of each of the following effects: Alternating, Chase, Pulse, Set Level, Spin, Twinkle.
Search for the "_dataModels" tag. The effects will all be in that section. You'll see that each effect basically just has XML representations of the data fields presented in the effect editor. The color(gradient) and curve objects may be a bit confusing but it's how vixen creates these sorts of objects. Gradients are a description of colors that change over time, and curves are values that change over time.
I just created a simple sequence with one of each of the following effects: Alternating, Chase, Pulse, Set Level, Spin, Twinkle.
Search for the "_dataModels" tag. The effects will all be in that section. You'll see that each effect basically just has XML representations of the data fields presented in the effect editor. The color(gradient) and curve objects may be a bit confusing but it's how vixen creates these sorts of objects. Gradients are a description of colors that change over time, and curves are values that change over time.
jchuchla
Supporting Member
The Whole sequence is wrapped in a TimedSequenceData tag. Then inside of that are all the stuff that makes a sequence. You can ignore the tags on lines 3 thru 17 and everything below line 424 except the final closing tag.
The effect data is all within the _dataModels tag.
Each effect is in a tag that looks like:
d1p1:anyType xmlns:d2p1="http://schemas.datacontract.org/2004/07/VixenModules.Effect.Alternating" where that last part is the effect name/type.
Set level is the simplest example. It contains one color (not a gradient) and a level (not a curve)
Pulse extends that one step further and changes the color and level to a gradient and curve.
You can see the complexity of the object structure gets progressively more complex as the effects get more complex. But the same basic building blocks are the same in all of them. All gradients are the same. All curves are the same. Etc...
The effect data is all within the _dataModels tag.
Each effect is in a tag that looks like:
d1p1:anyType xmlns:d2p1="http://schemas.datacontract.org/2004/07/VixenModules.Effect.Alternating" where that last part is the effect name/type.
Set level is the simplest example. It contains one color (not a gradient) and a level (not a curve)
Pulse extends that one step further and changes the color and level to a gradient and curve.
You can see the complexity of the object structure gets progressively more complex as the effects get more complex. But the same basic building blocks are the same in all of them. All gradients are the same. All curves are the same. Etc...
The esp- 07 would be a better choice and it has external antenna if desired.
Without looking it up, I don't think so. It only has 4 GPIO pins (+Power, Ground, Reset and CH_PD/EN).
Last edited:
It's too big, it won't fit in the floral tubes that I've purchased (inner diameter at the entrance to the tube is almost exactly the width of an ESP-01, which is why I needed to force it in). Besides, I like a challenge.
Sorry , I hadn't considered the real estate issue .
OK, I've read through the file, and have somewhat of an understanding. As I see it, lines 19-422 specify instances of the effects Alternating, Chase, Pulse, SetLevel, Spin and Twinkle (in that order), while lines 425-497 specify the times when each of these effects are active on some set of nodes. However, I couldn't find the specification of which nodes these effects are applied to (I think that there is some other file that contains these specifications).
I don't think that it would be too difficult to change my code for the ESP module to better align with those file structure(s).
jchuchla
Supporting Member
The node information is stored in the SystemConfig.xml file. SystemConfig contains the parts of the display profile that relate to the core vixen functions. ModuleStore.xml is the other main profile file. It contains the data for all the parts of the profile that come from plugins/modules. (which does include a lot of what you might consider base functionality as well). I don't know if you actually need the rest of the node information from SystemConfig or not. I guess you might need it so that you can decide if the ChannelNodeReferenceSurrogate is a root element or a group, and if it's a group, you'll need to enumerate the child elements to determine the effect behavior.
The sample sequence file I created was based on my real profile. If i were to share the corresponding SystemConfig, it would be a very large file that would be a challenge to parse by hand. You'd probably want to create a fresh sample profile and generate a sample sequence against it so that you get corresponding GUIDs with a config file that's manageable.
The current version of the sequence files contains a reduced definition of the node structure. This was added a few years ago to facilitate sequence sharing between profiles. It contains just enough info about the nodes to aid in mapping when the sequence is opened on a foreign profile. I was wrong in my initial description. You're right. The timing of the effects is in the EffectNodeSurrogates tags. There'll be one EffectNodeSurrogate for each d1p1:anyType. They're linked by the Instance ID. How the effect descriptor tag got that name is beyond me. the serialization of the objects is abstracted and handled by a separate serializer library. So there's some behind the scenes stuff happening in the generation of the XML that we don't fully control.
The sample sequence file I created was based on my real profile. If i were to share the corresponding SystemConfig, it would be a very large file that would be a challenge to parse by hand. You'd probably want to create a fresh sample profile and generate a sample sequence against it so that you get corresponding GUIDs with a config file that's manageable.
The current version of the sequence files contains a reduced definition of the node structure. This was added a few years ago to facilitate sequence sharing between profiles. It contains just enough info about the nodes to aid in mapping when the sequence is opened on a foreign profile. I was wrong in my initial description. You're right. The timing of the effects is in the EffectNodeSurrogates tags. There'll be one EffectNodeSurrogate for each d1p1:anyType. They're linked by the Instance ID. How the effect descriptor tag got that name is beyond me. the serialization of the objects is abstracted and handled by a separate serializer library. So there's some behind the scenes stuff happening in the generation of the XML that we don't fully control.
Thanks. My experience with Vixen3 is quite limited (a few hours of playing with it back in August), and I need more time playing with it to see how easy (or not) it will be to modify my controller firmware to align with the Vixen3 mindset and to write a translator program. I'm quite optimistic about this approach, though.
jchuchla
Supporting Member
I think this is probably the closest approach to "parametric sequencing" that I can think of. You will probably want to limit your scope of sequencing with regard to effects and channel count to best suit your device. But this certainly sounds easier than writing a sequencer from the ground up.