Curious why a front end was not developed

[charleskerr]

Ok, I know I am new to this area, and am lagging behind others in terms of development. However, it was fairly common in my field of RF and Signal processing, to develop modules to perform common functions. For instance, we may have a receiver, but it was common to have a sub band tuner sitting behind that, that every processor had, to sub select a spectrum of data out of the main one.


I see the input data stream as the same thing. One has a data stream (be it DMX, or anything), and essentially, every controller or device needs to select a subset of data out of that stream, perhaps do a minor processing (such as normalization mapping), and then take that data and post process it for the specific device type that the output needs.


I was curious why a standardized "front end" so to speak wasn't developed, to quickly aid in the development of new controllers. In the old day communication world, this eliminated errors and development time (we used a proven front end), and only had to worry about the back end.


I am right now having to make that decision with my front end (to either make it truly a stand alone module, or just duplicate it every time which isn't has good as traces and board layout has to be checked each time). I was curious, as this group is ahead of me in terms of evolution/development in this arena, the possible reasons why that didn't occur (or what the trade offs might have been).


Appreciate any insight.

 

[David_AVD]

I must say I'm a bit confused. (yeah yeah, old man syndrome!) Are you talking about hardware or software modules?

 

[charleskerr]

Well both.


Say you had a small board/module that had the following (say we are doing standard DMX, we may change a bit for E1.31)




Hardware module:


1. 485 level convertor
2. PIC
3. RF-45 jack for connection
4. Two pins out for SPI or other standard interface


All this module does is accept data stream , understand what subsection of the DMX is needed, applies curves, and then outputs it via api (perhaps control lines in saying if data is ready to be received, otherwise output is skipped).


If this was available, then this module would never change regardless of what LED/lights you want to use, for that would be the same (front end). I haven't seen any of the DIY kits offering this universal board so if others developed E1.31, or something, it could just be swapped out to someones back end, and one is up and running.


Perhaps I should do a drawing.


But if this front end allowd the basics (like pixel string size, etc), device type, etc, then it could be used for DC, AC, LED controllers.


I was just curious, as this is/was common in the old RF field, if there was some reason this hadn't been done in the DIY christmas light world.

 

[David_AVD]

I like a modular approach as much (or more?) than the next guy, but most of the time this hobby boils down to lowest cost and smallest size. As such, application specific designs tend to win out over modules almost every time.

 

[AussiePhil]

Charles

Quite a few reasons spring to mind
Cost
Dual PC complexity
Firmware still needs to be written
Universal design becomes complex and costly
Hardware developer independance
History

History plays a major role especially in the non-pixel, non E131 world of controllers. Prior to DMX arriving on the scene controllers fell into two camps, LOR/AL and DIY designs using serial/parrallel ports. DMX only arrived into the xmas controller scene in 2008 and the hardware developer didn't publish circuits or firmware so modular development was unlikely to occur from there.
Cost then becomes a driving overruling factor, the DIY community for which this would be aimed want the cheapest possible price on a controller PCB so creating a second pcb they had to buy would never work. Even when i developed two designs with identical DMX front ends it was not economically sensible to make a pluggable module.
Firmware: even if you make the module, what hardware do you chose, 16F/18F/24F/PIC32/ETC, the developers have varied skills in firmware development and providing a 18F or Pic32 module to the renard community would have been a waste of time due to the code base in 16F. Renard with all it's code base similarity would have been a better candidate for a module but it never occurred. Regardless the hardware developer would still need to code firmware for the module that may not fully fit the requirements.
Universal Design: you design the module to have SPI out but I want I2C, now you have multiple requirements to cater for increasing cost due to greater capacity processor etc.

The "front end" as you put it is in itself quite simple for DMX, RS485, Terminator and some sort of micro, it becomes a copy and paste exercise between circuits with the PCB layout taking minutes.... it may even take longer to layout a pluggable module layout.

Now in the E131 area there is some validity in the modular approach and J1Sys has already gone down that path for some products, however as size requirements came to the fore the "front end" became the controller and the module bacame the extensible options, so even in this space the "universal" module is less applicable than it looks at first glance.

I'm not convinced the comparison to RF "front ends" is valid but it does create and interesting talking point.

Cheers
Phil

 

[kool-lites]

Charles,
to add the already comprehensive responses, most of the benifits you are describing are mandated by engineering management constraints in particular ROI and TOM. Professionally, when you have made considerable investiment in Tool chains, training on the same tools, PCB layout/simulation tools and production aids/training, you need to devise ways for making you product development shorter and cheaper while working within your organisation's commercial restraints. Even moving to a new uController family may require business case!
In this hobby the tool chains are free, most use very low cost Layout tools, and rarely are incentivised to meet dead lines. Who cares is the latest design takes a month or two to be released? Another aspect is most developers hold their opions are very important and must be followed (once again this is not an issue in the work place cause they have a different commitment/engagement model), this hobby is no different. I would say this is a major benifit as it bring diversity, and the challenge of forums like this and DIYC.com is to foster diversity.
Things have probably changed now, but previous attempts to have standard biulding blocks were not as useful as they seemed. On a commerical microwarve radio that had idendical Modulators across all radio modules, when we copied the block we loast all the Net list information and thus it became faster to just layout the block out again.
Cheers
Matt