i must have the code for detecting a missin g pulse? do some one have some for me to see?
G !
The standard problem.
If you have a question, you must supply a complete problem description.
It sounds like you may have a g sensor - but we don't know which, or how it is connected. And we don't know why you would have lost G pulse to even figure out that you have lost. Exactly how do you loose it?
If you do not know enough to give a complete problem description, then neither you nor we may have a chance of knowing the answer.
Per, I must disagree. There is nothing wrong with providing an 'answer' with the same thoroughness as the question.
Answer (start here...)
library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; --============================================================================ -- ENTITY for "The Case Of The Missin G Pulse" -- --============================================================================ entity mPulse is Port ( -------------------------------------------------------------- -- IO port definitions -- -------------------------------------------------------------- RST : in std_logic; -- Reset all states to known values Clock : in std_logic; -- The time-base Pulses : in std_logic; -- The incoming pulse train Enable : in std_logic; -- Enables the function Missin : out std_logic -- The result (without the 'G') ); end mPulse;
And then you simply write the architecture as needed. It almost writes itself.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
lol gatmal
i made mistake!!!!! alrigt!!!!!!!
it is {{{not}}} a missin g pulse . it is a missing pulse.
aneybody answer me now plz?????
"it is a missing pulse.
aneybody answer me now plz?"
Sure, but first, describe "a missing pulse"?
I stand corrected. Will try to redeem myself.
// \note The following library is dependant on the current // geographical location (latitude + longitude + // distance from the mean earth radius) moon // location, speed and travel direction, and sensor // orientation, since the g pulse // detector is calibrated relative to the local // gravitational levels (and influences of coriolis // forces) at the sensor location. // \todo A laser gyro and GPS tracker should be integrated // for automatic adjustments of the reference limits // for the g pulse sensor, and to allow detect failures // to be reported in relation to the GPS reference time. // \note Calibration or orientation differences between // G and H pulse sensors will affect the reliability of // the error detector. The H pulse detector should normally // be calibrated with a higher detect level (percentage // depending on current security classification) to // make sure that a too sensitive H pulse sensor generates // alarms when the G pulses are just below the detection // levels. bool have_seen_g_pulse; bool any_g_missing; bool last_g_missing; unsigned detector_timeout; timestamp time_last_failure; timestamp time_first_failure; void init(void) { // Initialized to true even if no G pulse seen yet, // to make sure we don't get a false error in case // the supervision is started between a G and an H // pulse. have_seen_g_pulse = true; any_g_missing = false; last_g_missing = false; comm_failure = false; detector_timeout = get_now() + COM_FAILURE_TMO; clear_timestamp(time_first_failure); clear_timestamp(time_last_failure); } void report_g_pulse(void) { if (detector_timeout()) { if (!any_g_missing) { get_timestamp(time_first_g_missing); } get_timestamp(time_last_g_missing); last_g_msising = true; any_g_missing = true; } have_seen_g_pulse = true; last_g_missing = false; detector_timeout = get_now() + COM_FAILURE_TMO; } void report_h_pulse(void) { if (!have_seen_g_pulse || detector_timeout()) { // Since everyone knows that H always follows G, // a detect of H without a G implies a lost // G. if (!any_g_missing) { get_timestamp(time_first_g_missing); } get_timestamp(time_last_g_missing); last_g_msising = true; any_g_missing = true; } // Arm detector. have_seen_g_pulse = false; detector_timeout = get_now() + COM_FAILURE_TMO; comm_failure = false; } bool detector_timeout() { return get_now() > detector_timeout; } bool have_mmissed_last_g_pulse(timestamp* when) { if (last_g_missing) { if (when) *when = time_last_g_missing; return true; } if (detector_timeout()) { if (!any_g_missing) { get_timestamp(time_first_g_missing); any_g_missing = true; } get_timestamp(time_last_g_missing); last_g_missing = true; comm_failure = true; if (when) *when = time_last_g_missing; return true; } return false; } bool have_missed_any_g_pulse() { if (any_g_missing) { if (when) *when = time_last_g_missing; return true; } if (detector_timeout()) { if (!any_g_missing) { get_timestamp(time_first_g_missing); any_g_missing = true; } get_timestamp(time_last_g_missing); last_g_missing = true; comm_failure = true; if (when) *when = time_last_g_missing; return true; } return false; }
Well done Per! NP Complete!
thxxx
i will tr yit now
Hello,
It would appear that some people here have too much spare time on their hands!?
Clearly, but Per is still my hero!
<admire>Clearly, but Per is still my hero!</admire>
I think that this forum should show pictures of all the top posters. Then we could all see the true beauty of wisdom.
robhan visan,
A way to detect it is to monitor the pulses, determine the time between them, and then determine if a pulse is missing based upon the expected time it should have occurred.
Pseudo-code:
if( pulse ) { capture time difference in time = (current time) - (previous time); if( difference > expected time ) { missing pulse has occured } else { missing pulse has not occured } }
a close 'C' approximation:
#define EXPECTED_TIME_BETWEEN_PULSES 50 // >50ms means too much time void pulse_isr( void ) // a logic pulse interrupts CPU { static unsigned int current_time = 0; static unsigned int previous_time = 0; int difference; current_time = Get_Timestamp( ); // needs a timing routine accessor difference = ( current_time - previous_time ); if( difference > EXPECTED_TIME_BETWEEN_PULSES ) { Flag_Missing_Pulse = TRUE; // the flag that say's "Missing" } else { Flag_Missing_Pulse = FALSE; } previous_time = current_time; // for next time }
This example will let you know that a missing pulse occurred one pulse AFTER it has been 'missed.'
There are better ways to do this, but this is just an example.
I hope you get a good grade on this assignment.
NOTE: Per still needs some redeeming... his "H follows G" rule doesn't account for the field-tested sobriety research data collected over the past 30+ years. So the real-world missing pulse detector must not rely on this H-G relationship.
P.S. FYI... I found Jack's photo...
inpraiseofsardines.typepad.com/.../sardine_man_1.jpg
But my code _does_ watch out for a timeout between two G pulses, in case you have problems with the H detector, or for some reason have managed to run the alphabet in the reverse order :)
Per really does not need my advocacy, but for your information, this guy is by all means one of most knowledgeable people around here. If you want to take on somebody, well, you better pick me...
Another one for the collection of "rahib kalib"?
:-)
But how can you be sure that it occurred...?
;-)
Andy, Andy, Andy,
How can you be so nieve? This is Embedded Systems 101...
You must also do this:
#include <Heisenberg.h>
Then call:
Observer_Effect( DISABLED ); Test_For_Missin_G( ); Observer_Effect( ENABLED );
before you begin any missing pulse testing algorithms (and then re-enable it after the testing).
You must treat these real-world tests like you would any other atomic instruction or routine.
What happens if you forget to call
Observer_Effect( ENABLED );
when you are done?
Also...would it be possible to create a predictive algorithm based on the spin of G to determine when the missing pulses will occur?
HELLO @@@ HOGAR HERE.
If I understood your problem correctly , you can use a re-trigger able mono-shot with 2 to 4 Sec delay. Re-trigger this mono shot by the pulses in your problem.
If this trigger pulses misses the mono-shot will no longer will get trigger and it will change the state.
This state of the mono-shot can be used to trigger your alarm circuit. Hope I am clear.
Regards
hohar itp
[rememba, i am unique, just like you and you and you]
i am unique
Oh, yeah.
The required delay must be chosen according to the expected repetition rate of the G pulses - how do you know that 2-4s is anywhere near the requirement?
I agree with hogar,
Brillient solution.
Simply use a "Dual retriggerable monostable multivibrator" type 74hc123 to sense two pulse (use two same ICs for 4 pulses and so on ... )
Study the datasheet here: www.nxp.com/.../74HC_HCT123_4.pdf
I think it's possible to realize the circuit without any processor... it's a really "older" solution.
Good luck
zuisti
(chef programmer)
Kind moderators!
I see more letters, which I did not write, on this forum. Somebody abuse my name, and my other letters written onto an other forum are copied here, modified many times. I ask it - if possible - let it be deleted, and I call upon the perpetrators in order for it to be stopped though!!
The real zuisti, an old (65) engineer from...(you know it I think). And ... I'm NOT a chef programmer !!
chef programmer
You know, a modern microwave owen can be quite hard to program. Some chefs may need a specially appointed programmer to handle the more complicated cuisines.
you can use a re-trigger able mono-shot .... I agree with hogar, Brillient solution.
My name for a monostable is "One shot in the foot"
monostables are so awfully noise prone that they are more likely to cause problems than solve them.
Of course you can use a 4 or 6 layer board with a schmitt located within millimeters of the OneShot 'isolating' the trigger and 12 decouplig caps surrounding the OneShot and maybe get lucky.
Erik
PS for our foreign friends, an American expression for making problems for yourself is "shooting yourself in the foot"
"monostables are so awfully noise prone"
They're just trying to make up for all the other pulses that he's lost...
In a high-end digital scope, you have to use very special designs to catch ps glitches.
But as soon as the pulses gets within "computable" range, I do recommend using a pin interrupt, port interrupt or a timer or similar to handle the detect of the pulse, or timeouts waiting for pulses. It consumes a single pin on the processor - and an external circuit will also require some transfer capability of the processor. But the advantage of being able to change the timeout value or possibly switch between positive or negative flank, ... by just updating a software parameter can be invaluable.
And a later software may be updated to look at the variance between the pulses, allowing detection of vibrations in a mechanical system or slow acceleration in an electrical motor or similar. Real hardware is nice to have when the processor lacks the capability of handling a problem. In most other situations, software is recommendable. A late software update may be the difference between winning or loosing an important deal - either by being able to match a competior, or to differentiate from them.
View all questions in Keil forum