|
To me, it reads like the standard version, which supports up to 64 cameras, is the higher price. There's also a "lite" version, supporting a single camera (and hence presumably not including various other features, like multi-camera view, camera selection and switching etc) for a reduced price. Which makes sense - if you've got really basic needs, with just a single camera, you can still access the core functionality. Once you've licensed the more complex software, with multi-camera capability, they're not charging you more whether you have 2, 10, 20 or 60 cameras. Remember the pricing is just for the software license, not for the hardware.
|
|
|
|
|
I understand the pricing. What I don't understand is how they decided to charge that and to only have two versions. Especially given that the second is so much more functional.
|
|
|
|
|
well, just that. Either the full version (that includes multi-camera support); or a cut-down "lite" version that doesn't. As soon as you want more than one camera, you need multi-camera support, by definition.
|
|
|
|
|
Still a question about how the decision was made for the specific pricing model.
For example consider the following model.
1. 1 camera $40
2. 16 camera $80
3. 32 camera $200
4. 64 camera $1000
First is to experiment.
Second is a home system or small business.
Third is a medium business.
Fourth is a larger business (not national corporation but rather a single operation which has quite a bit of space.) Perhaps for example a larger self storage operation with indoor and outdoor storage.
|
|
|
|
|
That involves artificially building in additional logic to entirely arbitrarily limit the number of cameras. And you'd probably need a way to upgrade when a 16-user customer wants to add another one.
Maybe the company just want to keep it really simple. "Lite" version or "Normal" version. It's a pricing model I've used for licensed software in the past. Easy to build, easy to sell, easy to support. Wish more companies did it.
|
|
|
|
|
DerekT-P wrote: That involves artificially building in additional logic to entirely arbitrarily limit the number of cameras
Of course. So?
One of Microsoft OS versions did exactly that. There was a flag that turned it from Home to Professional.
DerekT-P wrote: And you'd probably need a way to upgrade when a 16-user customer wants to add another one.
And thus more money. Which is the point of companies.
DerekT-P wrote: Maybe the company just want to keep it really simple
Yes but the point is to actually make money. Otherwise give it away for free. That is why picking a pricing model is so important.
Especially with a product like this where it would be easy to differentiate.
|
|
|
|
|
So there is a cheap single-camera version, and a more expensive multi-camera version that can handle up to 64 cameras.
Fair enough. You want another multi-camera version with a different (lower) max limit on # of cameras. Like a sound editor that can handle a file at a time in the 'basic' version but can mix up to 64 sound files in the 'pro' version, and you request a 'semi-pro' version that can mix up to 16 sound files. Maybe even a 'low-pro' version for 32 files. I don't think you will get it. Either you have the 'multi' functionality or you don't.
You may think that paying twice as much for the 'multi' capable version is a lot. My immediate reaction is that I'd expect an even bigger price difference. Handling multiple streams introduces so much added complexity (which is very little dependent on the number of streams once you go from 1 to 2) that it should be reflected in a significantly higher price tag.
I do not think that $40 for the 'multi' functionality is any terrible overpricing.
|
|
|
|
|
trønderen wrote: You want another multi-camera version with a different (lower) max limi
No. The question is about the pricing model. The price to me does not matter. But rather that they could certainly charge more for the largest one.
To me the first version is rather trivial. Except for experimenting I don't really see that, for most cases, it is useful. Certainly not, for example, sufficient to provide a home security set up.
But the only other solution seems like over kill for anything except a business which is not that small. For example a corner store would not need that many cameras. But perhaps a gas/grocery with multiple pumps and inside isles might be getting up to that limit. But for that need then they can afford, especially as a one time cost, more than that. If nothing else consider the cost of the cameras and installation in comparison.
|
|
|
|
|
So the model with 'single' functionality is not useful, but the 'multi' version that can handle 64 cameras is overkill.
Maybe you could ask for something like that in, say, Windows as well: Being able to open hundreds of windows is overkill; you want a cheaper Windows that handles only a few windows. Or, NTFS easily handles a million files; you want to pay less for a file system handling at most 65535 files.
Here in Norway, the highest speed limit is 110 km/h. I find it unreasonable that all the cars offered can easily reach 200 km/h. I want a car that is identical with that, but locked at 110 km/h at a lower price. Why can't I get it?
I never take more than 256 MByte worth of pictures with my digital camera before emptying them to my PC. Why can't I buy a memory card with 1/128 the capacity of a 32 GByte card at 1/128 the price? I don't need those 32 GBytes!
Sorry, if you want offerings in the market to be tailor made to fit your needs exactly, then you'll have to pay the price for a tailor made suit. I guarantee you that it won't be cheaper than a standard suit.
Half of multi-stream handling is still multi-stream handling. Halving the number of streams makes no simplification of software development and maintenance.
Sometimes manufacturers decide to sell a product below production cost to capture low-budget customers (hoping that the budget of these customers may grow in the future). In the early 1980s I worked for a company making 32-bit superminis. The company could afford developing a 'cheap' line for low-budget customers; they had to capture them by selling the standard model cheap. So they were searching for ways to 'castrate' the cheap model. One proposal - a serious one, not meant as a joke - was to insert wait cycles in the microcode between every macro-instruction, to slow the machine down. The winning proposal was a better one: Pull out the cache memory. That saved about USD 40,000 in component costs - that is how expensive cache memory was 40 years ago! You can more than triple it for the price level of today.
Lots of complex software packages is offered in similar 'castrated' versions, usually disabling some function that you really need, so that you will regret not buying the full version. You make it sound like you want the complete functionality of the full version, only with a lower number of cameras. You won't get that. If the manufacturer made an 'intermediate level', you can be assured that a handful of essential multi-channel functions would be disabled.
Second: No manufacturer would take that effort to save you $20 ($60 rather than $80)! How many BigMac is that? $20 is small change. Maybe the vendor would it to offer you a machine at $20,000 less (or even a software package - there is software costing that much).
So 1 camera is the toy version. The 'real' version sells at $80. If you need the real version, pay the $80, and don't worry about the software having higher capacity limits than you need, functions that you don't use. All software is like that.
|
|
|
|
|
trønderen wrote: Sorry, if you want offerings in the market to be tailor made to fit your needs exactly
Seems to be some confusion about what I am asking.
I don't care how they sell the product.
I was starting a conversation about how that company decided to do their price modeling. Thus the process through which an individual or company makes a decision on how to price the product/service.
|
|
|
|
|
jschell wrote: I was starting a conversation about how that company decided to do their price modeling.
The problem is that you completely refuse to accept that is twice as costly (actually, the factor is probably higher) is sold for twice the price. You seem to insist that reducing an array size will reduce development and maintenance cost so much that the product should be sold for a significantly lower price.
That is an incorrect assumption. The same program system with half as big a camera connection array costs just as much to maintain as a full capacity one. The company has no justification at all, based on real costs, for selling an 8 or 16 camera version any cheaper than a 64 camera version.
So if they followed your line of thought, reducing the array size to 8 and disable a few essential functions, and then raise the price tag for the 64 camera model to $120, you would have it your way: A fewer-camera (and reduced functionality) model at a lower price than the full blown one. It would be your way, but not cheaper for you. It would be to suck the maximum amount of money from the market, regardless of their own real expenses.
This is not according to my ideals. I do not want a manufacturer to manipulate prices to squeeze the market. Ideally, the sales price of any product should reflect the real cost of manufacturing it - obviously with a not unreasonable margin for the manufacturers return on investment, transportation costs and things like that. I strongly dislike when two products with identical production costs are sold at significantly different prices for the sole purpose of market manipulation.
I have tried to get this through in my previous entry: This is my thought about the price modeling of this company. That it is sound and right. You seem to be unwilling to understand that I have been talking about the price modeling all the time, by supporting the price model that they have today.
I am sorry for that. I clearly see that you are searching for someone agreeing with you, that this price modeling is horrible, that you should be able to get an 8-camera version for a significantly lower price than the 64-camera version. When I do not support you in this, you apparently refuse to see that I am talking about the price modeling.
Bottom line, if you still are unable to relate my comments to the price modeling:
I support that company's price modeling. I do not support your demand for a cheaper version for fewer cameras.
|
|
|
|
|
trønderen wrote: The problem is that you completely refuse to accept that is twice as costly (actually, the factor is probably higher) is sold for twice the price. You seem to insist that reducing an array size will reduce development and maintenance cost so much that the product should be sold for a significantly lower price.
I didn't say anything at all about any of that.
trønderen wrote: This is not according to my ideals. I do not want a manufacturer to manipulate prices to squeeze the market
Then you probably are not the best one to discuss actual price modeling.
The fact is that successful companies make money. The more money they make the more likely that they will continue to exist. And do other things like support the product when OS/hardware changes occur. And a specific example in this case might be that if there is a problem with a specific camera vendor the company can afford to and might find it profitable to buy the camera and figure out the problem.
trønderen wrote: that you should be able to get an 8-camera version for a significantly lower price than the 64-camera version.
No that doesn't state what I said. I pointed out that in the market there will be different types of users and those users will have different needs. Thus the company could provide different product offerings appropriate for those types and, to the benefit of the company, make more money.
trønderen wrote: I do not support your demand for a cheaper version for fewer cameras.
First I didn't "demand" anything.
Second I did not request that it be "cheaper". Exactly the opposite in the example I suggested in that it should be more expensive for the the current top offering. That is then offset with the addition of one or more midline offerings.
|
|
|
|
|
About a week ago, we still had snow drifts. Yesterday it was 27C. Today all the trees, shrubs and grass are starting to green. And I get to chase after the dog and mow the lawn.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
And the maple syrup! You need to start collecting maple syrup!
Btw it started "boing" here a few days back and my Bernese Mountain dog hates it. For him any temperature above zero degrees is an abomination.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
I get an Orange Pi PC some time between the 12th and the first of June. It's my last ditch effort to get xboot running on an ARM based SoC chip - an AllWinner H3 in this case. The Secondary Phase Loader code is what eludes me. I can't find it for xboot. I don't even know if it is *in* xboot. It might be. I can only find SPLs for linux and android, and u-boot, a tool for creating those SPLs for linux.
So far I have not even been able to successfully use the FEL capability of any of this hardware to directly inject xboot code into the device's RAM via USB and execute it even thought it has that capability, and I have done that injection, but got a black screen.
It could be because I was using a 480p LCD and xboot doesn't support it with the default config. So I spent $80 on a new compact 720p screen, which still doesn't show signal. I've probably dropped over $200 trying different boards and equipment now.
It could be any number of things. Lately I haven't even been able to do the injection process because the device isn't enumerating anymore. - update: it enumerates and injects xboot, but black screen
Also these boards don't expose the pin you need to drop the board into FEL mode where you can do the above injection. You have to flash an SD card with a special image to drop the board into FEL mode so you can do the injection, with no way to tell if it actually worked other than trying to inject.
All of this is in Chinese. All of this is scattered across Chinese forums where I've even posted, but haven't received responses. Probably doesn't help that I'm posting in English but I trust the ability of Chinese tech people to read English more than I trust google translate
There is so much going on in this rickety workflow and toolchain setup that anything could go wrong, and it's usually impossible to find out what failed.
That's why I'm close to giving up and instead building a quick loading linux build, except for the fact that I have to launch X server to do any graphics at all. 
Damn these things.
To err is human. Fortune favors the monsters.
modified 4-May-23 9:48am.
|
|
|
|
|
If you follow your usual pattern I expect to see a post in the near future boldly proclaiming, I've cracked it ! 
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
I appreciate the vote of confidence.
To err is human. Fortune favors the monsters.
|
|
|
|
|
We need to collect all your posts into a book "What it is really like to be an Embedded Systems Developer".
You let us know about your frustrations and failures followed by the Eureka Moment of success.
Reminds me of my days developing custom microprocessor systems in the 80s. Things like debugging a flaky board and the scope probe correcting the bad IC socket connection, or the scope ground fixing a missing ground connection.
We are all cheering you on and sitting on the edge or our seats wondering what Out-Of-The-Box solution you will come up with.
"Mistakes are prevented by Experience. Experience is gained by making mistakes."
|
|
|
|
|
Thanks. I hope it doesn't put too many people off. I know some don't care for the technical nature of a lot of my forum posts, but to me the struggles of development seem like they should be right at home in the lounge. What kind of coders would we be if we didn't swap war stories? 
To err is human. Fortune favors the monsters.
|
|
|
|
|
Embedded Development is 49% swearing at Chips, 11% swearing at the "person" who told you to do it & 40% alcohol dependency mixed with luck... 
|
|
|
|
|
|
You're annoying every now and then...
.... but you're annoying in a pleasant way and more importantly in an informative way  
|
|
|
|
|
There's so much frustration in embedded work, but that little ray of sunshine makes it worth the effort.
Give me coffee to change the things I can and wine for those I can not!
PartsBin an Electronics Part Organizer - An updated version available! JaxCoder.com
Latest Article: Simon Says, A Child's Game
|
|
|
|
|
These kinds of issues during one of my senior labs is why I stuck with software.
Did the TA know that the chip I am using had a burned out address line? And the next one as well? A4 vs A12, and we figured out the second one a LOT faster.
Third chip worked fine.
|
|
|
|
|
I know this feeling when it happens
Why why why, did I get into engineering?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
