Feature Request Thread

C

chilloutdocdoc

New member
Re: NEW - PropController Project

Just a list of all of our current feature requests for the board. I will try to keep the post updated, maybe once some of these start getting their own thread, we can link to that.

Place all feature requests in this thread.


Software:
  • Renard Rx
  • sACN (E1.31) as Stand Alone Object
  • ---- Register MAC via ICMP
  • Read MAC from Microchip EEPROM
  • Optimize Art-Net Code
  • Channel Patch with ability to configure
  • DMX RDM Object (requires in-depth ASM knowledge, PM DynamoBen for code)
  • Ledtriks Object
  • Serial Configuration
  • ---- Coding practices (standards for drivers)
  • ---- Code
  • Web Configuration Object

Hardware:

To be Tested:
  • ArtNet
  • GE Color Effects
  • Channel Driver
  • BAM (bit angle modulation)

Full Project Board Configurations:
  • sACN (E1.31) -> DMX
  • GE Color Effects
  • sACN (E1.31) -> Renard
  • sACN (E1.31) -> Pixels
 
Last edited by a moderator:
Re: NEW - PropController Project

chilloutdocdoc said:
How long do you figure before we start tying up some loose ends on the PropController Project? There's a lot of things still to be written, and not a lot of direction. I think most of us have been waiting for you to lead on the project, and without much direction, we (or maybe just be) have been idling without much to go on.
Click to expand...

It can and should start now if folks have interest. Like most open source projects the direction comes from what people need. I wrote the code that exists in the project for two reason one was I needed it for my show (the dimmer projects) the other was to meet potential needs I saw in the community (the RGB pixel string and Renard drivers).

Completed ready to run projects would be a good thing, also having new daughter boards with drivers. Testing and improving on the projects and drivers that are already up would be a good thing. Really the sky is the limit.

What can I do to help promote development? What needs to be worked on? What is unfinished?

Loose ends I can think of:

The RGB drivers, with the exception of one, are written to use one output pin. It would be awesome to make all of them work with 4 output pins.

I wrote the Renard driver but have no idea if it works. That needs testing and might need work, not to mention there is no hardware for it.

I have a strong start on an RDM driver, it requires a lot of ASM work which is why I keep putting it on the back burner.

I have a BAM (bit angle modulation) driver to dim LEDs, it needs testing and tweaking but budude isn't finished with the hardware yet. I am happy to post what I've got.

I started adding dimmer curves to the channel driver but got side tracked on those improvements.

The serial configuration code could be started. I don't have anything yet but the protocol exists in another thread.

Someone could try to figure out a modular way to do configuration via a webpage.

It would be nice to have a way to patch channels, the hard part will be figuring out how to configure the patch. (I did this on another project with an LCD and 4 switches, I could post that code)

I don't think we need to be quite as detailed as say Arduino's documentation and setup, but I think if we're aiming at having an OpenSource Development Aimed board, we need to make it developer and user friendly.
Click to expand...

Parallax has a wealth of development information and example code, so I think most of that info already exists. Combine that info with the schematic for the PropController and you are good to go.

With that said having "canned" or premade/modular projects would make it a lot more use friendly.

Can we get some people to volunteer for the tasks at hand (or even a list of said tasks at hand?) It's already June and time is winding down to where people don't want to be working on controllers, they want to be sequencing and setting up their show.
Click to expand...

The task list is going to be based on how people plan to use the PropController for their show this year.

Personally I need to create an input daugtherboard with driver for Halloween so I can trigger Vixen sequences via the network. In addition I could really use a servo board and driver. In my head the daughterboard would be a series of shift registers with a header for a supplemental power to run the servos. The OBEX has servo code to do this I just haven't gotten around to the hardware. Beyond those things I may also need a motor speed controller (hardware and a driver).
 
Re: NEW - PropController Project

I do have the hardware for the "Prop48LSD" laid out on a protoboard for testing. I can take the code now if you have it ready to go. Once the hardware is proven out, I'll commit it to the board layout. I "sort-of" have this done as well but need to swap the channel outputs end-to-end as I put them in reverse. It will use all through-hole parts. I'll post a pic of it once I swap around the outputs.
 
Re: NEW - PropController Project

I put the work in progress BAM code on the project site. Once its proven we can update it.
 
Re: NEW - PropController Project

I also have a very rough GE Color Effects object, but no hardware to work with. Anyone want that?
 
Re: NEW - PropController Project

Two more for the pile:

I have some older ArtNet code that I believe might still work but defiantly needs optimization.

I would also like to get the sACN code into its own object, the reason is so you can swap between network protocols by just changing objects (IE sACN to Artnet). At present part of the sACN code is in the parent object.
 
Re: NEW - PropController Project

Update: I've created an "unreleased" folder within drivers and posted some new code. This contains code that either needs testing or needs work. Once we have confidence that its working we can move it out of there.

New code includes ArtNet, GE Color Effects, Channel Driver /w some dimmer curve code. BAM and Renard are also in there because they both need testing and tweaking.

I've also added two enhancement requests under issues on the project site in regard to the Pixel drivers. I'm not sure if or how the rest of the info I posted should be captured on the project site. Wiki??

Also if you want to be added as a Project committer just PM your request to me.
 
Re: NEW - PropController Project

I'm going through right now rebuilding some of the E1.31 to DMX to suit my needs, adding a few features, taking a few out as i don't see them necessary.

Do you think we should create a template file for projects. It seems like the controller is mostly doing a Input, Process, Output (typical to computers huh?) which could be laid out. I'll put some stuff up in a bit to show what i'm talking about.

The channel patching feature you talked about is probably quite simple. Have a recieved buffer, a patch method, and an output buffer, each iteration of the loop, the recieved data goes in the first buffer, the patch moves the data around, and the output buffer is used by the output plugins.

Josh
 
Re: NEW - PropController Project

chilloutdocdoc said:
The channel patching feature you talked about is probably quite simple. Have a recieved buffer, a patch method, and an output buffer, each iteration of the loop, the recieved data goes in the first buffer, the patch moves the data around, and the output buffer is used by the output plugins.
Click to expand...

It is easy the hard part is the configuration of the patch when there is no UI. I have patching code, just no way to configure it.
 
Re: NEW - PropController Project

DynamoBen said:
Two more for the pile:

I have some older ArtNet code that I believe might still work but defiantly needs optimization.

I would also like to get the sACN code into its own object, the reason is so you can swap between network protocols by just changing objects (IE sACN to Artnet). At present part of the sACN code is in the parent object.
Click to expand...

When you say move the sACN code into it's own object, do you mean just copy the code over, or put it in a seperate cog then the "master"

Right now my ideal configuration would be

0: Master
1: Serial Configuration (calls functions in master)
2: sACN or Art-Net
3: Output1
4: Output2
5: Output3
6: Output4
7: Output5

Does this follow what you were thinking for a pretty basic "starting point"?
 
Re: NEW - PropController Project

chilloutdocdoc said:
When you say move the sACN code into it's own object, do you mean just copy the code over, or put it in a seperate cog then the "master"
Click to expand...

Actually if you look at the ArtNet code you will notice that it is a self contained object, any dependencies like the WizNet driver are bundled into it. All you have to do is add ArtNet to the parent code and start making calls to it. That object gathers all the data into a buffer where that data can be retrieved (similar to the DMX object).

The sACN code isn't like that at the moment. Most of the methods are in the parent code (it was easier to develop the proof of concept that way), it would be better to have a single object, and then make calls to it from the parent. That would also make swapping between protocols easier, a single object reference change and you are done.
 
Just a list of all of our current feature requests for the board. I will try to keep the post updated, maybe once some of these start getting their own thread, we can link to that.

Place all feature requests in this thread?


Software:
  • Renard Input added to current driver
  • GE Color Effects
  • sACN (E1.31) as Stand Alone Object
  • Read MAC from Microchip EEPROM
  • Optimize Art-Net Code
  • Channel Patch with ability to configure
  • DMX/RDM Driver
  • Serial Configuration
  • Channel Driver dimmer curves
  • Web Configuration
  • Register MAC via ICMP
  • Coding practices (standards for drivers)
  • Code

To be Tested:
  • ArtNet
  • GE Color Effects
  • Channel Driver
  • BAM (bit angle modulation)

Hardware:

Full Project Board Configurations:
  • sACN (E1.31) -> DMX
  • GE Color Effects
  • sACN (E1.31) -> Renard
  • sACN (E1.31) -> Pixels
 
Last edited by a moderator:
Re: To do

I just thought of two ethernet items that need to be done:

sACN requires the device to register its MAC via ICMP, not a big deal but should be done.
Also the new MAC eeprom needs to be implement, not sure if this should be in the ethernet driver or one level up.
 
Re: To do

Working on the ethernet driver now, I'll have to look up what ICMP means before I can understand what you just said :).

I'll add this to the current list. I should have a draft of the ethernet up tonight if I get a chance to at least test some functionality. It's very heavily modeled after your code.

Edit:
Do you think there is a use for a template object... to kind of make the code a bit more uniform-ish? or just let everybody go to their own style?
 
Last edited:
Re: To do

chilloutdocdoc said:
I'll add this to the current list. I should have a draft of the ethernet up tonight if I get a chance to at least test some functionality. It's very heavily modeled after your code.
Click to expand...

I can't take credit for the ethernet driver, I only had a small hand in the asm portion.

Do you think there is a use for a template object... to kind of make the code a bit more uniform-ish? or just let everybody go to their own style?
Click to expand...

I think this should cover it: http://www.parallaxsemiconductor.com/an011
 
OK - don't know if/how viable it is but it would be great to have something to drive the LEDTriks. It would require a new version of LTC (or something like it). I'm not even sure how the communication would work since it would have to share the connection and sync somehow with Vixen/LSP.
 
chilloutdocdoc said:
Maybe something that could emulate the Trix C?
Click to expand...

Yes - that is what I was thinking - however, we would need something to replace the Tim's LTC program as well so it's a two parter for this one. I'm guessing it would not be a trivial thing to implement. I'm open to a complete Triks Controller/Triks-C replacement as well to drive things directly but obviously that would be a bit more complex...
 
Not being very familiar with the triks, why can't we work on a drop in hardware solution before we do the software.
It would be a large partnership that I probably can't implement much on so it will have to remain on the list until somebody takes it up.
There is a renard based triks board I think that we can use with the renard output though, that could be a good start to eliminating hardware dongles.
 
budude said:
Yes - that is what I was thinking - however, we would need something to replace the Tim's LTC program as well so it's a two parter for this one. I'm guessing it would not be a trivial thing to implement. I'm open to a complete Triks Controller/Triks-C replacement as well to drive things directly but obviously that would be a bit more complex...
Click to expand...

Warning I'm going into the weed: A prop based trix might be cool.
 
You must log in or register to reply here.
Back
Top