I need to create a board that will contain about 50 LED’s. The LED’s need to be turned on/off individually, and together (timer is based on days suppose every Monday all the 50 LED’s turn on and every day of the week 10 LED’s are turned on).
In my research I have found the LM555 timer but that would lead to a huge circuit of 50 different timers
What is the most efficient way of controlling these LED’s
My first answer was really stupid (i'm so sorry about that) and i don't know why I didn't think before about the amazing "Shift Registers".
Your Arduino don't have so much pin to light every LEDs you had. But using shift registers this is possible. From an 8-bit shift register you can light 8 LEDs using just 2-3 PIN on your Arduino board (1 for clock, 1 for data and 1 for latch).
So to light 50 PINs you just need 7 of this components (for example).
How to use it? There are a lot of tutorials on internet, usually the sparkFun tutorial is my favorite.
Below: an image from Arduino site. It explained how to connect 16 LEDs.
Anyway from the software side, what you have to know ShiftOut function.
After that you have to use time function.
First of all initialize your time variables as you can see in link I posted above.
After, in your loop:
Put HIGH your Datapin connected to 50 leds when previousMonth != month.
Put HIGH dataPin connected to 10 leds when daySum == 10 (so, when previousDay != day you have to increase daySum using daySum++).
Related
I am working on the ESP32 microcontroller and I would like to implement iBeacon advertising feature. I have been reading about the iBeacon. I have learnt about the specific format that iBeacon packet uses:
https://os.mbed.com/blog/entry/BLE-Beacons-URIBeacon-AltBeacons-iBeacon/
From what I understand, iBeacon preset is set and not meant to be modified. I must set a custom UUID, major and minor numbers such as:
uint8_t Beacon_UUID[16] = {0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF};
uint8_t Beacon_MAJOR[2] = {0x12,0x34};
uint8_t Beacon_MINOR[2] = {0x56,0x78};
The only thing that I am confused about is the TX Power byte. What should I set it to?
According to the website that I have referred above:
Blockquote
A scanning application reads the UUID, major number and minor number and references them against a database to get information about the beacon; the beacon itself carries no descriptive information - it requires this external database to be useful. The TX power field is used with the measured signal strength to determine how far away the beacon is from the smart phone. Please note that TxPower must be calibrated on a beacon-by-beacon basis by the user to be accurate.
Blockquote
It mentions what is TxPower and how it should be determined but I still cannot make any sense out of it. Why would I need to measure how far away the beacon is from the smart phone if? That should be done by the iBeacon scanner not the advertiser(me).
When you are making a hardware device transmit iBeacon, it is your responsibility to measure the output power of the transmitter and put the corresponding value into the TxPower byte of the iBeacon transmission.
Why? Because receiving applications that detect your beacon need to know how strong your transmitter is to estimate distance. Otherwise there would be no way for the receiving application to tell if a medium signal level like -75 dB is from a nearby weak transmitter or a far away strong transmitter.
The basic procedure is to put a receiver exactly one meter away from your transmitter and measure the RSSI at that distance. The one meter RSSI is what you put into TxPower byte of the iBeacon advertisement.
The specifics of how to measure this properly can be a bit tricky, because every receiver has a different "specificity" meaning they will read a higher or lower RSSI depending on their antenna gain. When Apple came out with iBeacon several years ago, they declared the reference receiver an iPhone 4S -- this was the newest phone available at that time. You would run beacon detection app like AirLocate (not available in the App Store) or my Beacon Locate (available in the App Store). The basic procedure is to aim the back of the phone at the beacon when it is exactly one meter away and use the app to measure the RSSI. Many detector apps have a "calibrate" feature which averages RSSI measurements over 30 seconds or so. For best results when calibrating, do this with both transmitter and receiver at least 3 feet above the ground and minimize metal or dense walls nearby. Ideally, you would do this outdoors using two plastic tripods (or do the same inside an antenna chamber.)
It is hard to find a reference iPhone 4S these days, and other iPhone models can measure surprisingly different RSSI values. My tests show that an iPhone SE 2nd edition measures signals very similarly to an iPhone 4S. But even these models are not made anymore. If you cannot get one of these, use the oldest iPhone you can get without a case and take the best measurement you can as described above. Obviously a ideal measurement requires more effort -- you have to decide how much effort you are willing to put into this. An ideal measurement is only important if you expect receiving applications to want to get the best distance measurements possible.
I have the following LED array:
LED Circuit
I need help calculating the power supply needed. Rather than sticking it on an adjustable power supply, setting the current limit to 700mA and turning up the voltage I would prefer to learn how to calculate the optimal voltage. The LEDS and 1W and limited to 700mA and instead of just 5 columns my actual circuit has 14 columns. Please can someone teach me how to do the calculations for this circuit. If it were a straight forward parallel string of LEDs, I would not bother you, but the additional junctions throw me off a bit.
Please don't suggest alternative layouts as this is what I am reverse engineering.
Thanks,
Dylan
I have a setup with a Beaglebone Black which communicates over I²C with his slaves every second and reads data from them. Sometimes the I²C readout fails though, and I want to get statistics about these fails.
I would like to implement an algorithm which displays the percentage of successful communications of the last 5 minutes (up to 24 hours) and updates that value constantly. If I would implement that 'normally' with an array where I store success/no success of every second, that would mean a lot of wasted RAM/CPU load for a minor feature (especially if I would like to see the statistics of the last 24 hours).
Does someone know a good way to do that, or can anyone point me in the right direction?
Why don't you just implement a low-pass filter? For every successfull transfer, you push in a 1, for every failed one a 0; the result is a number between 0 and 1. Assuming that your transfers happen periodically, this works well -- and you just have to adjust the cutoff frequency of that filter to your desired "averaging duration".
However, I can't follow your RAM argument: assuming you store one byte representing success or failure per transfer, which you say happens every second, you end up with 86400B per day -- 85KB/day is really negligible.
EDIT Cutoff frequency is something from signal theory and describes the highest or lowest frequency that passes a low or high pass filter.
Implementing a low-pass filter is trivial; something like (pseudocode):
new_val = 1 //init with no failed transfers
alpha = 0.001
while(true):
old_val=new_val
success=do_transfer_and_return_1_on_success_or_0_on_failure()
new_val = alpha * success + (1-alpha) * old_val
That's a single-tap IIR (infinite impulse response) filter; single tap because there's only one alpha and thus, only one number that is stored as state.
EDIT2: the value of alpha defines the behaviour of this filter.
EDIT3: you can use a filter design tool to give you the right alpha; just set your low pass filter's cutoff frequency to something like 0.5/integrationLengthInSamples, select an order of 0 for the IIR and use an elliptic design method (most tools default to butterworth, but 0 order butterworths don't do a thing).
I'd use scipy and convert the resulting (b,a) tuple (a will be 1, here) to the correct form for this feedback form.
UPDATE In light of the comment by the OP 'determine a trend of which devices are failing' I would recommend the geometric average that Marcus Müller ꕺꕺ put forward.
ACCURATE METHOD
The method below is aimed at obtaining 'well defined' statistics for performance over time that are also useful for 'after the fact' analysis.
Notice that geometric average has a 'look back' over recent messages rather than fixed time period.
Maintain a rolling array of 24*60/5 = 288 'prior success rates' (SR[i] with i=-1, -2,...,-288) each representing a 5 minute interval in the preceding 24 hours.
That will consume about 2.5K if the elements are 64-bit doubles.
To 'effect' constant updating use an Estimated 'Current' Success Rate as follows:
ECSR = (t*S/M+(300-t)*SR[-1])/300
Where S and M are the count of errors and messages in the current (partially complete period. SR[-1] is the previous (now complete) bucket.
t is the number of seconds expired of the current bucket.
NB: When you start up you need to use 300*S/M/t.
In essence the approximation assumes the error rate was steady over the preceding 5 - 10 minutes.
To 'effect' a 24 hour look back you can either 'shuffle' the data down (by copy or memcpy()) at the end of each 5 minute interval or implement a 'circular array by keeping track of the current bucket index'.
NB: For many management/diagnostic purposes intervals of 15 minutes are often entirely adequate. You might want to make the 'grain' configurable.
I am making a finger plethysmograph(FP) using an LED and a receiver. The sensor produces an analog pulse waveform that is filtered, amplified and fed into a microcontroller input with a range of 3.3-0V. This signal is converted into its digital form.
Smapling rate is 8MHz, Processor frequency is 26MHz, Precision is 10 or 8 bit.
I am having problems coming up with a robust method for peak detection. I want to be able to detect heart pulses from the finger plethysmograph. I have managed to produce an accurate measurement of heart rate using a threshold method. However, the FP is extremely sensitive to movement and the offset of the signal can change based on movement. However, the peaks of the signal will still show up but with varying voltage offset.
Therefore, I am proposing a peak detection method that uses the slope to detect peaks. In example, if a peak is produced, the slope before and after the maximum point will be positive and negative respectively.
How feasible do you think this method is? Is there an easier way to perform peak detection using a microcontroller?
You can still introduce detection of false peaks when the device is moved. This will be present whether you are timing average peak duration or applying an FFT (fast Fourier Transform).
With an FFT you should be able to ignore peaks outside the range of frequencies you are considering (ie those < 30 bpm and > 300 bpm, say).
As Kenny suggests, 8MHz might overwhelm a 26MHz chip. Any particular reason for such a high sampling rate?
Like some of the comments, I would also recommend lowering your sample rate since you only care about pulse (i.e. heart rate) for now. So, assuming you're going to be looking at resting heart rate, you'll be in the sub-1Hz to 2Hz range (60 BPM = 1Hz), depending on subject health, age, etc.
In order to isolate the frequency range of interest, I would also recommend a simple, low-order digital filter. If you have access to Matlab, you can play around with Digital Filter Design using its Filter Design and Analysis Tool (Introduction to the FDATool). As you'll find out, Digital Filtering (wiki) is not computationally expensive since it is a matter of multiplication and addition.
To answer the detection part of your question, YES, it is certainly feasible to implement peak detection on the plethysmograph waveform within a microcontroller. Taking your example, a slope-based peak detection algorithm would operate on your waveform data, searching for changes in slope, essentially where the slope waveform crosses zero.
Here are a few other things to consider about your application:
Calculating slope can have a "spread" (i.e. do you find the slope between adjacent samples, or samples which are a few samples apart?)
What if your peak detection algorithm locates peaks that are too close together, or too far apart, in a physiological sense?
A Pulse Oximeter (wiki) often utilizes LEDs which emit Red and Infrared light. How does the frequency of the LED affect the plethysmograph? (HINT: It may not be significant, but I believe you'll find one wavelength to yield greater amplitudes in your frequency range of interest.)
Of course you'll find a variety of potential algorithms if you do a literature search but I think slope-based detection is great for its simplicity. Hope it helps.
If you can detect the period using zero crossing, even at 10x oversampling of 10 Hz, you can use a line fit of the quick-n-dirty-edge to find the exact period, and then subtract the new wave's samples in that period with the previous, and get a DC offset. The period measurement will have the precision of your sample rate. Doing operations on the time and amplitude-normalized data will be much easier.
This idea is computationally light compared to FFT, which still needs additional data processing.
I am using NXP LPC17xx family microcontrollers (LPC1759 and LPC1768).
How can I determine if RTC is running for sure?
I am doing a test on
LPC_RTC->CCR & RTC_CCR_CLKEN
but it seems no much reliable.
I have seen values in year 3197 or so when turning on my device.
How can I tell if RTC is running and its value is not corrupt?
EDIT:
I ended up adding a simple sanity check in RTC values:
bool DateTime::validate( const RTC_TIME_Type &time_info )
{
if ( time_info.YEAR > 2100
|| time_info.DOY > 366
|| time_info.MONTH > 12
|| time_info.DOM > 31
|| time_info.HOUR > 23
|| time_info.MIN > 59
|| time_info.SEC > 59 )
return false;
return true;
}
It is run during my POST, as suggested bellow.
I battled with the RTC on that chip's grandfather (LPC2148) about 5 years ago. If you look on the Yahoo LPC2000 group (it also covers the LPC1000 chips) you'll see the RTC & its issues come up a lot.
Anyway, I'm going from memory here, but I think I concluded that reading the status register wasn't reliable enough. Maybe the issue was that when power was removed, if the battery backup was absent, things would get scrambled...
So what I recall I did was the following, during the boot phase:
(1) Enable RTC peripheral
(2) Read ALL RTC registers. In firmware, have "out of bounds" min & max values for each field (e.g. year must be at least 2005, and no larger than 2030)
(3) If any value is out of range, reset date & time to some hard-coded value (e.g. Jan. 1, 2005) (product would let user adjust time/date once booted)
(4) Take snapshot of registers; wait AT LEAST one second (use timer peripheral to measure time), then make sure the value changed. I might have gone so far during boot-up as to set the values so that a 1-second tick would/should cause everything to roll over (probably 1 second before midnight, Dec. 31), ensure everything changes, then write back the original value + 1 second. (You would want to do this right as the value changes to avoid slipping seconds)
I will try to dig up the code and see if there was something more. I just recall finally concluding I had to run the damn thing & watch it work before I passed the P.O.S.T. for that peripheral.
(I kind of mentioned it in passing, but just to re-iterate... if your values seem corrupted on power-on, make sure your battery back-up circuitry is rock solid - even a basic circuit with a pair of diodes normally suffices. Could be that the clock is running when the product is running, but that when power is removed, its brains get scrambled.)
Also confronted with temperamental rtc's here....
I don't think a really reliable test is possible, you could store the last recorded time somewhere in non volatile memory, and check that the clock hasn't moved to a past date, and you can also test that the delta between two checks is not too big. That would catch something like the year 3000, but you cannot reduce the tested time lapse to say 1 month - you want the thing to wake up even if it was shelved for say a year.
Do you have the possibility to consult a time source at startup? Eg an ntp server or some other device that your controller speaks with that can be considered synchronized with a reliable time source?
You can route the RTC clock to an external pin and watch it on an oscilloscope or a logic analyzer.
IIRC I did just that for LPC1766/1768 (I have two identical boards populated with different processors).