Commercial Opportunity: Monitoring

XCore Project reviews, ideas, videos and proposals.
User avatar
Berni
Respected Member
Posts: 363
Joined: Thu Dec 10, 2009 10:17 pm
Contact:

Post by Berni »

Oh if it has to run for so long it makes sense to harvest energy using a solar cell or similar


User avatar
daveg
Member++
Posts: 28
Joined: Thu Dec 10, 2009 7:25 pm

Post by daveg »

jonathan wrote:It must be capable of reporting periodically (daily) on the number and pattern of inputs remotely - preferably via a mobile phone network. The device must be battery-operated and the aim is to last for at least a calendar year before a battery replacement is necessary.
Without something like a solar panel, wind power or some other form of power (mains!) the "...via a mobile phone network" and "...at least a calendar year..." clauses seem incompatible to me.
User avatar
___
Member++
Posts: 30
Joined: Wed Feb 03, 2010 5:04 pm

Post by ___ »

Image
Last edited by ___ on Wed Apr 14, 2010 3:16 pm, edited 2 times in total.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm
Contact:

Post by jonathan »

This was as much a design challenge to assess viability as anything else. I've had some interest from a couple of people and will follow up with them either privately or publicly.

There are potential sources of energy from the surrounding environment - solar and mains are not really an option.

It should go without saying that it is more helpful to say: "I think at best you're talking x months, we could do that using y and if we had z then we could potentially harvest energy" than "1 year?! Impossible!". The former begins a discussion, the latter serves no real purpose at all.

Thanks for all the positive contributions, keep them coming!
Image
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm
Contact:

Post by jonathan »

I actually don't think this is anywhere near as challenging as some of you guys are making out.

The input will be infrequent. It should be possible to sleep 99.9% of the time, running the DSP for recognition as and when there is input loud (? audio input isn't the only potential input here, there are others) enough to wake up the main microprocessor to check for a "match".

The required connectivity with the mobile networks is minimal (enough to send a few byte summary every day or so).
Image
User avatar
andrew
Experienced Member
Posts: 114
Joined: Fri Dec 11, 2009 10:22 am

Post by andrew »

what's the duration of the thing you want to wake up on? if its a few seconds to a min then no buffer would be required, however, if its on the order of milliseconds then the dsp would need to be buffering in order for the main processor to have something to work on.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm
Contact:

Post by jonathan »

andrew wrote:what's the duration of the thing you want to wake up on? if its a few seconds to a min then no buffer would be required, however, if its on the order of milliseconds then the dsp would need to be buffering in order for the main processor to have something to work on.
Few seconds.
Image
User avatar
andrew
Experienced Member
Posts: 114
Joined: Fri Dec 11, 2009 10:22 am

Post by andrew »

what's the environment that this is in? what would the signal (positives) to noise ratio (false positives) be like?

you would want to be fairly certain that the sound was a match before switching the main processor on to save on power.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm
Contact:

Post by jonathan »

andrew wrote:what's the environment that this is in? what would the signal (positives) to noise ratio (false positives) be like?

you would want to be fairly certain that the sound was a match before switching the main processor on to save on power.
I don't know much about audio processing. I suspect if you calibrated whatever the "wakeup signal" was correctly there would be very few false positives. Essentially, there is background noise but only one potential source of the target sound, which is probably also the closest source of sound.

I can definitely give a few more details of the very specific instance via PM if you're interested - I'm also interested in the more general case to see how well you can do from a system design perspective... Clearly the frequency of the input and signal to noise ratio will pretty much determine the battery life. The main (battery lifetime) challenge seems to be whether you can find some way to only burn power when you're actually pretty certain you need to... Which clearly means NOT running the audio processing constantly.
Image
User avatar
Berni
Respected Member
Posts: 363
Joined: Thu Dec 10, 2009 10:17 pm
Contact:

Post by Berni »

How about using the same chip as the DSP and MCU, say a dsPIC. There is a human voice recognition library out there and the thing can switch its clock in a few cycles. The ADC can also operate during sleep mode. Also since the sounds are not very frequent it means it can be down clocked to a little clock and reduce its awake current to a minimum.

Only thing i'm not so sure of is the connection to the cellular network as GSM modules can be have quite large costs. On the other hand it does not need support for any of the more advanced technologys like GPRS or 3G as you can simply dialup the few bytes in to the Internet.
Post Reply