Handling hundreds of digital I/O

WBahn

Joined Mar 31, 2012
29,979
I had in mind a single module that contains the electronics (CPU, radio, etc), lamp, power supply (from mains), and sensor (probably cheap CCD video), and lots and lots of software. One module could be bolted to the ceiling of the parking garage for each space, or mounted on poles sans ceiling. All the modules would mesh and report their status to a master PC somewhere on the internet. I bet I could manufacture something like this for somewhere between $20 and $50 ea. in high volume.
Yep. That is why I said that having one module per space that integrates a sensor and an indicator "has some obvious attractions to it". I'm merely pointing out that there are lots of options that can/should be considered.

For the TS's purposes, it probably doesn't matter too much how low cost something like this could be manufactured in high volume unless there is someone out there actually manufacturing it in high volume (and, who knows, there might be). If they end up actually having to design and build the system (or have someone do so for them), then a very different set of tradeoffs come into play -- in particular the NRE on that "lots and lots of software". Of course, even here putting everything into a self-contained module has potential NRE advantages over separate sensor/indicator solutions.

One option, instead of image analysis (though there are an increasing number of open-source packages for that available) is to use a radar module. It shouldn't take as much processing to decide if the space is available and it should be able to manage interference from other units pretty easily given the time frames involved.
 

joeyd999

Joined Jun 6, 2011
5,237
in particular the NRE on that "lots and lots of software".
These days, I much prefer to solve complicated problems in software than hardware, regardless of code size and effort. Software is more flexible, and can be "repaired" far later in the design/production cycle and at a much lower cost.

Speaking of: they don't teach economics anymore to engineering majors?
 

joeyd999

Joined Jun 6, 2011
5,237
When I was in school, hundreds of years ago, we at least had to produce a BOM for our projects and justify the cost based on NRE, labor, price, and projected margins. No more?
 

WBahn

Joined Mar 31, 2012
29,979
These days, I much prefer to solve complicated problems in software than hardware, regardless of code size and effort. Software is more flexible, and can be "repaired" far later in the design/production cycle and at a much lower cost.

Speaking of: they don't teach economics anymore to engineering majors?
It would seem to me that the notion of "regardless of code size and effort" is not very compatible with taking an economics view of any problem.
 

WBahn

Joined Mar 31, 2012
29,979
When I was in school, hundreds of years ago, we at least had to produce a BOM for our projects and justify the cost based on NRE, labor, price, and projected margins. No more?
I certainly can't speak for all programs, but in general undergraduate engineering programs have significantly de-emphasized practical considerations, both technical and non-technical. Some of this is a simple reflection of there being a lot more engineering theory content that the powers-that-be feel just simply must be included while a lot of it is a reflection that most engineering faculty have little to no actual engineering experience in the real world. I have heard, many times, phrases like, "We are educating engineers, not training technicians," when I have suggested that we need more hands-on, practical projects of significant size and scope in the curriculum.
 

joeyd999

Joined Jun 6, 2011
5,237
It would seem to me that the notion of "regardless of code size and effort" is not very compatible with taking an economics view of any problem.
It's more a rule of thumb I've developed over the years: software solutions to complex problems tend to be less expensive than hardware solutions -- from start to finish.

I've enough experience to quickly judge in my head whether or not to take a software approach prior to embarking on a project. Usually, I minimize the hardware and let software do most of the heavy lifting.
 
Top