Guys I want to ask if possible to create a solar powered automatic bell system with smoke detection using raspberry pi? And I worries if the raspberry pi have real time clock? Because I need a RTC to execute the bell in exact alarm for certain interval I set.
This the statement I find in internet for more details but the author used an arduino.
The system uses the real time clock to determine
the time and the bell rings based on set up time. The LCD
in this system displays current time and displays fire if
the smoke detector detects a smoke. For different
sessions, the bell will ring different numbers of times.
The system is expected to continuously display the time
by using real time clock and monitor the situation of the
school during the day and night with power generated by
solar energy [9]. By using solar energy as a power source,
the system is uninterrupted during power supply failure
from the main energy department. In addition, the energy
can be used efficiently during day time and stored energy
in the battery can be utilized during night time. This
designed bell system integrated with smoke detector
integration is expected to safeguard the institution from
damages and losses particularly during an outbreak of
fire.
Your project is indeed feasible. The RPI check for the smoke detector value at a certain interval of time. If the value is higher than a certain threshold then you ring your bell.
The raspberry pi does not have a RTC included. You'll have to buy one online (a simple research on google should lead you to online shop like adafruit ...). But I don't understand why you would need to use a real time clock. If you want to use this system (which I don't recommend ; use a certified equipment for your personal security) you should check the data from the smoke/fire detector quite regularly but it doesn't have to be matching real time clock.
Alternatively, you could use RPI WiFi/Ethernet to request RTC from the internet.
If you are doing this project just for fun, use a smoke detector and a buzzer. Your RPI should be able to provide enough current to power both of these equipment. You could power your RPI with a small battery or a charger (check the correct voltage & current needed by the RPI).
You should find a lot of information/tutorials/code online for these type of little projects.
I have a vehicle with a tracker installed. The device has a gps syst, 3-axis accelerometer, 3-axis magnetomet and a gyromeyet. Is it possible to determine by how much the vehicle rolled back on a slope or hill. Using gps angle wasn't an option as the angle given for short backward movement isn't always reliable. Can accelerometer be used in such a scenario??
You're right that the GPS angle (heading) will not help you in a single-antennae setup. On its own a GPS receiver needs a minimum distance of movement to determine heading.
A simple GPS receiver, when used without GPS corrections (which is the case for off-the-shelf GPS devices and mobile phones/tablets), has a minimum ~5 meter accuracy. That's why a short backward movement will not yield the desired results.
In construction/mining applications, there is often a fixed GPS base station nearby that broadcasts GPS corrections, which allows vehicle-mounted GPS receiver to apply corrections, reduce error and ultimately get centimeter-level accuracy.
So in conclusion, your 3-axis accelerometer will likely be the only sensor that you can rely on until your vehicle has rolled back at least 5 meters.
If your accelerometer is sensitive enough, you'll get measurable sensor values. However, if you rollback is very slow, where the G forces are almost imperceptible to the accelerometer, then you're out of luck.
This is assuming that you want near real-time detection of vehicle rollback.
I'm using a Mediatek MT3333 GPS receiver (baudrate: 115200 bpS), but all I'm getting is this:
b'$GNGGA,132002.448,,,,,0,0,,,M,,M,,*5C\r\n'
b'$GPGSA,A,1,,,,,,,,,,,,,,,*1E\r\n'
b'$GLGSA,A,1,,,,,,,,,,,,,,,*02\r\n'
b'$GPGSV,1,1,00*79\r\n'
b'$GLGSV,1,1,00*65\r\n'
b'$GNRMC,132002.448,V,,,,,0.00,0.00,100417,,,N*5A\r\n'
b'$GNVTG,0.00,T,,M,0.00,N,0.00,K,N*2C\r\n'
After some research I found that my receiver doesn't have a fix, any idea how to solve this?
It looks that the received signal strength is low so that your GPS receiver mode doesn't get a GPS FIX. It would be better to place the device outdoor to verify if there is a stable reception.
From the GPS sentences showed above, your Mediatek MT3333 GPS receiver output modified NMEA 0183 Sentence. All the standard sentence should started with $GP as the suffix and with format of $GPaaa, where aaa is alphabetic.
For instance,
b'$GNRMC,132002.448,V,,,,,0.00,0.00,100417,,,N*5A\r\n' should be read as
$GPRMC,132002.448,V,,,,,0.00,0.00,100417,,,N*5A if conforms to NMEA. This sentence tells that at 2017-04-10 12:30:02 (GMT) got no GPS fix with speed at 0 knot and course at 0 degree.
If the output of your GPS receiver conforms NMEA, you can use some free software, such as VisualGPS, to evaluation the GPS signal quality.
If possible, suggest to change the GPS antenna to external one, an active GPS antenna with 2-stage amplifier at around 28dBm gain, to improve the GPS signal reception in order to get a stable fix.
From the datasheet of Mediatek MT3333, it did mention below for improving GPS signal reception:
An external antenna and high gain external LNA connected to the
internal LNA in low-gain mode, which offers high linearity. In this
configuration, external LNA gain ranging from 15 to 20 dB is
recommended. The maximum total external RF front end gain including
active antenna and external LNA can be 43dB.
Hope this help.
I just bought Digital heart beat rate sensor:
http://www.dealextreme.com/p/digital-heart-beat-rate-sensor-3-5mm-data-port-16009
And I'm looking how I can make application for iOS to work with.
Sensor has 3.5mm jack and I can detect signal with audio framework on iOS.
Can you give me some guidelines how to start with detecting these signals into heart beat rates?
That sensor looks rather like one I have here in my junk box. If so, it generates a voltage signal which depends on the pressure exerted on it by the skin against which it is pressed. If there is a strong pulse at the point of pressure, I see a signal on an oscilloscope which has a component at the pulse rate: so it is at a frequency of around 1-2Hz.
This is WAY below the audio range, and in most audio interfaces would be filtered out before it ever got to the audio in ADC. I don't have a handy iPhone to check this on, but it would be bad design if the audio input did let such frequencies through. And Mr Jobs (R.I.P.) did not approve of bad design!
There is also a lot of interference at other frequencies: mains hum (50Hz here), and at lower frequencies spurious signals from muscle twitches.
To make this work, you would need some sort of signal conditioning. If it was up to me, I would use a high input impedance amplifier, with about a 0.1Hz - 10Hz passband, followed by a voltage to frequency converter. That would give me a tone, which i could set in the audio band, whose frequency varied up & down as the pressure on the sensor changes. That would let me use fairly simple frequency detection software to recover the pressure waveform, which could then be processed using autocorrelation or similar techniques to recover the heartbeat frequency. A DTMF decoder is not the right tool, though.
I did find when I played about with the senor that it was very touchy, responding to almost everything going, and it wouldn't be easy to pick out the heartbeat. Your sensor may be different, though.
I'm new to the world of GPS. Please help me understand the following:
1) Why GPS chip is required? If the GPS antenna is enough to transmit and receive data, any normal processor could do the decoding of the received GPS data.
2) Does NaviLink 6.0 has its own GPS stack? Doesn't Android has its own GPS stack?
3) NaviLink 6.0 integrates A-GPS, Bluetooth 2.1, FM Tx/Rx on a single chip. Why do you require a chip for bluetooth for FM and Bluetooth? Is FM antenna not enough? Is a separate chip required for Bluetooth too?
it's possible, and it's called "Software GPS" (there is even an open source project)
however, the CPU resources required are really big, and therefore its not really an option for hand-held mobile devices.
also, the sampling rate need to be very high, ad you need A/D converter, which also complicate things