I am just wondering if it is possible to display a sentence, for example "SOLD OUT", on the 7-segment display of the FPGA board where I can only show four letters.
I want it to display SOLD then OUT.
If it is possible to implement that, how can I do it? Clock divider?
You start by researching what the board does. How does it connect to the LCD display? What are the waveforms required to drive a value to the display. It will be different for different boards. The Digilent boards tend to be common Anode. Some Altera boards connect all four 7-segment displays directly to FPGA IO (wastes IO, but who cares when you have plenty).
Next you determine, how do I display a character on the display. What holds the value? What translates the value from an internal representation, such as ASCII to the value on the display.
WRT clocks, my preference is to use a common FPGA clock and use load enables that provide periodic indication it is time to load the other image.
Think about how fast you should be switching the display? My recommendation is to make sure you display each value for 1 sec before switching and adjust after you see it working. If you decrease the display time too much, your display will blur because neither value is displayed long enough.
Next how do I display 4 characters?
Next how do I make the characters shift or alternate between different values. This could be a character wide shift register, it could be two different display registers.
In each of these steps you should be drawing a picture of the hardware before writing any code.
Related
When the radio is of Ieee80211DimensionalRadio radio type, why doesn't the INET 4.4 have a communicationRange parameter?
If not, please help how to set this parameter.
The reason is the same, why a WiFi card in a real computer does not have a setting where you can set how far the WiFi card can communicate. You do not set range in a real system. You set the transmission power and the effective range depends on that.
In short, you have to calculate the required power backwards from the range. Obviously, that is extremely complicated assuming that there are error correction, directional antennas, non-freespace propagation, etc..
The best you can do is to manually change the TX power and experiment to set it to a level suitable to you.
(additionally: There is no such thing as communication range in real world. There is always a probability that a packet is received for any distance. The question is, where you set your cutoff probability. This is always subjective).
I am not an electrical engineer, however I am putting together an Arduino Nano Led Matrix 40x20 Led grid, I was wondering what power supply I should use so everything works properly without destroying anything.
This is what was recommended for a 10x10 grid. 5V 4A Power Supply: http://amzn.to/1UhdJfB
I will also be using WS2812B LEDs if that makes any difference. Also if you know a good software to make the led animations that would be great too, the software I have is limiting.
According to the pololu website
Each RGB LED draws approximately 50 mA when it is set to full brightness and powered at 5 V
a 10x10 grid consists of 100 leds, i.e. 5A, so 4A is undersized (if you try to light them all at full brightness and white you may experience problems).
This said, 40x20 leds are 800 leds, which means 40A (plus the arduino). This current is really high, and requires proper thinking about HOW to deliver this to the leds.
You can find a lot of power supplies on the web (a quick search on ebay found a lot of power supplies for about 25 USD, just search 5v 40a and you'll find a list of them); personally, since the price difference is low, I'd go with a 5v 60a power supply, so you are not pushing it to its limit when full brightness is on.
Then, how to deliver it. I tend to oversize everything, but I'd group the leds in 10 groups of 80, then connect a thick wire (at least AWG14 or bigger) to both ends of each group and then pull all of them to the power supply. The data lines can be daisy chained together. Something like this:
The green wires are connected to Din, the blue ones to Dout. In short, you have to group the 20 rows in 10 groups, power each group with a separate wire (the AWG14 wires should go directly to the power supply, each will deliver up to 4A) and daisy chain the data wires of the groups.
If you have questions, just ask ;)
You can use 5V supply since most of devices including arduino, matrix display use 5V. Amp rating of supply varies according to the number of devices (LED's) connected. If you are using WS2812B LED (RGB) u can use 3.5~5.3V.
To program arduino nano you can use official arduino ide from their official site, using which you can do limitless patterns expandable upto your imagination.
I have a table, where each row of the table contains state (registers). There is logic that chooses one particular row. Only one row receives the "selected" signal. State from that chosen row is then accessed. Either a portion of the state is connected as an output to the IO of the module, or else a portion of the IO is used as input to update the state.
If I were implementing this with a circuit, I would use pass-gates. The selected signal would turn on one set of pass-gates, which would connect the row's registers to a bus. The bus would then be wired to the IO bundle. This is fast, small area, and low energy.
There is a straight forward way of implementing this in Chisel. It encodes the selected row as a binary number, and then applies that number to the select input of a traditional mux. Unfortunately, for a table with 20 to 50 rows, and state of hundreds of bits, this implementation can be quite slow, and wasteful in area and energy.
The question has two parts:
1) Is there a way to specify busses in Chisel, such that you have pass-gates or traditional tri-state drivers all hung off the bus?
2) Failing that, is there a fast, small area, low energy way of doing this in Chisel?
Thanks
1) Chisel does not fully support bidirectional wires, but via the experimental Analog type (see example), you can at least stitch a bus through your Chisel code between Verilog Black Boxes.
2) Have you tried Mux1H in chisel3.util? It emits essentially a sum of products of the inputs and their corresponding select bits. I'm not sure how this compares to your proposed implementation. I would love to see a QOR comparison. If this construct is not sufficient and you cannot express precisely what you want in chisel, you can use a parameterized BlackBox to implement your one-hot mux and instantiate it as you please.
Quick Summary:
I'm looking for an algorithm to display a four-digit speed signal in such a way that the minimum number of (decimal) digits are changed each time the display is updated.
For example:
Filtered
Signal Display
--------------------
0000 0000
2345 2000
2345 2300
2345 2340
0190 0340
0190 0190
0190 0190
Details:
I'm working on a project in which I need to display a speed signal (between 0 and 3000 RPM) on a four-digit LCD display. The ideal display solution would be an analog gauge, but I'm stuck with the digital display. The display will be read by a machine operator, and I would like it to be as pleasant to read as possible.
The operator doesn't really care about the exact value of the signal. He will want to know what the value is (to the nearest 10 RPM), and he will want to see it go up and down in response to changes in the operation of the machine. He will not want to see it jumping all over the place.
Here is what I have done so far:
Round the number to the nearest 10 RPM so that the last digit always reads 0
Filter the signal so that electrical noise and normal sensor fluctuations don't cause the reading to jump around more than 10 RPM at a time.
Added a +/-10 RPM hysteresis to the signal to avoid the cases where it would wobble over the same value (for example: 990 - 1000)
This has cleaned things up nicely when the signal is steady (about 75% of the time), but I still see a lot of unnecessary variation in the signal when it is moving from one steady state to another. As the signal changes from 100 RPM to 1000 RPM (for example), it passes through a lot of numbers along the way. Since it takes a moment to actually read and comprehend the number, there seems to be little point in hitting all of those intermediate states. I tried simply reducing the update rate of the display, but that did not produce satisfactory results. It made the display "feel" sluggish and jumpy, all at the same time. There would be a noticeable delay before the numbers would change, and then they would move in big leaps (100, 340, 620, 980, 1000).
Proposal:
I would like the display to behave as shown in the example:
The display is updated twice per second
A transition from one steady state to another should not take longer than 2 seconds.
If the input signal is higher than the currently displayed value, the displayed signal should increase, but it should never go higher than the input signal value.
If the input signal is lower than the currently displayed value, the displayed signal should decrease, but it should never go lower than the input signal value.
The minimum number of digits should be changed per update (preferably only one digit)
Higher-order digits should be changed first, so that the difference between the display signal and the input signal is reduced as quickly as possible
Can you come up with, or do you know of an algorithm which will output the "proper" 4-digit decimal number according to the above rules?
The function prototype, in pseudo-code, would look something like this:
int GetDisplayValue(int currentDisplayValue, int inputSignal)
{
//..
}
Sorry for the wall of text. I wanted to document my progress to date so that anyone answering the question would avoid covering ground that I've already been through.
If you do not need the data expressed by the 4th digit, and are strictly bound to a 4 digit display, have you considered using the 4th digit as an increase/decrease indicator? Flash some portion of the top or bottom of the zero at 2Hz* to indicate that the next change of the gauge will be an increase or decrease.
I think you could also do well to make a good model of the response of your device, whatever it is, to adjustments, and use that model to extrapolate the target number based on the first half second of the two second stabilization process.
*this assumes that you have the two updates per second you posited. Most 4 digit displays are multiplexed, so you could probably flash it at a much higher frequency with a little driver tweaking.
I think your proposal to change one digit at a time is strange, because it actually provides the user with misinformation... what I would consider would be actually to add much MORE state changes, and implement it so that whenever the signal changes, they gauge moves towards the new value in increments of one. This would provide an analog-gauge like experience and "animation" of the change; the operator would very soon recognize subconsciously that digits rotating in sequence 0,1,2... denote increasing speed and 9,8,7,... decreasing speed.
E.g.:
Filtered signal Display
0000 0000
2345 0001
0002
...
2345
Hysteresis, which you have implemented, is of course very good for the stable state.
This is a delicate question, and my answer does not cover the algorithmic aspect.
I believe that the behaviour that you represent in the table at the beginning of your posting is a very bad idea. Lines 2 and 5 display data points that are and never were in the data, i.e. wrong data, for the sake of user experience. This could be a poor choice in the domain of machine operation.
A lower update rate may "feel sluggish" but is well defined (only "real" data and at most n milliseconds old). A faster update rate will display many intermediate values, but the most significant digits shouldn't change to quickly. Both are easier to test than any pretty false value generation.
This will incorporate more or less slowly the sensor value into the displayed value:
display = ( K * sensor + (256 - K) * display ) >> 8
Choose K between 0 (display never updated) and 256 (display always equal to sensor).
Is there an algorithm or some heuristic to decide whether digital audio data is clipping?
The simple answer is that if any sample has the maximum or minimum value (-32768 and +32767 respectively for 16 bit samples), you can consider it clipping. This isn't stricly true, since that value may actually be the correct value, but there is no way to tell whether +32767 really should have been +33000.
For a more complicated answer: There is such a thing as sample counting clipping detectors that require x consecutive samples to be at the max/min value for them to be considered clipping (where x may be as high as 7). The theory here is that clipping in just a few samples is not audible.
That said, there is audio equipment that clips quite audible even at values below the maximum (and above the minimum). Typical advice is to master music to peak at -0.3 dB instead of 0.0 dB for this reason. You might want to consider any sample above that level to be clipping. It all depends on what you need it for.
If you ever receive values at the maximum or minimum, then you are, by definition, clipping. Those values represent their particular value as well as all values beyond, and so they are best used as outside bounds detectors.
-Adam
For digital audio data, the term "clipping" doesn't really carry a lot of meaning other than "max amplitude". In the analog world, audio data comes from some hardware which usually contains a "clipping register", which allows you the possibility of a maximum amplitude that isn't clipped.
What might be better suited to digital audio is to set some threshold based on the limitations of your output D/A. If you're doing VOIP, then choose some threshold typical of handsets or cell phones, and call it "clipping" if your digital audio gets above that. If you're outputting to high-end home theater systems, then you probably won't have any "clipping".
I just noticed that there even are some nice implementations.
For example in Audacity:
Analyze → Find Clipping…
What Adam said. You could also add some logic to detect maximum amplitude values over a period of time and only flag those, but the essence is to determine if/when the signal hits the maximum amplitude.