I'm in the process of updating an old BS2 (basic stamp) Rev for an Ardunio for a piece of hardware for the company I work for, and I've just encountered a couple pieces of code that I'm not too sure on and I'd like some clarification. I've looked for a bit, but a couple of these are just not listed anywhere. I can't post the full code here for obvious reason, so I'll clarify other information as needed.
CONVERT_AD:
CONFIG_AD = CONFIG_AD |%1011 'Set all bits except channel.
LOW CHIP_SELECT 'Activate the ADC.
SHIFTOUT DATA_IO,CLOCK,LSBFIRST,[CONFIG_AD\4] 'Send config bits.
SHIFTIN DATA_IO,CLOCK,MSBPOST,[AD_RESULT\12] 'Get data bits.
HIGH CHIP_SELECT 'Deactivate the ADC.
RETURN
The line that's got me here is the CONFIG_AD = CONFIG_AD |%1011. It appears to obvious be a binary conversion, but I don't know what the operators are in this case. It looks like a 'assign'.
The value of CONFIG_AD is a word, if that's of any importance. It is hooking a pin for a half-duplex communication with a LTC1298 CN8 A-D converter. I've also read the data sheet, but it doesn't provide a lot of information regarding this. I think it's a 12 bit device? (though I'm not sure).
Just a lot of this information is really outdated and not maintained, so finding good information is really proving to be a bitch.
Also, the shift in/shift out, I'm curious why they have the two division functions on this? It seems to be converting it to another format, any explanation of why this is?
And on a slightly related note that is more of a save me time question, rather than I need to know, for the basic stamp, does anyone know it's hertz rates for the clock speed?
Related
This is an odd one. I'm not sure it's the right place to ask, but maybe there are some sound experts who can chime in? (no pun intended)
We use two sounds on our website to indicate success and failure on a quiz. Those are very simple and short sounds.
Somehow one of our customers reported that her dog was whimpering and really upset with both of those sounds. He's normally fine with lots of other sounds that dogs are typically unhappy with including loud sounds, hoovers etc. She even said it happens when she uses headphones!
Other than muting, or replacing those sounds (and upsetting other dogs?), is there anything we can do to clean the sound or detect what specifically makes them upset this or other dogs?
Downvoters: I think this question crosses over between biology/physiology/physics and signal and audio processing. The answers I'm getting now actually demonstrate this. It requires this cross-domain knowledge. In any case, I'm happy to delete it if this seems to not jive well with this community. I think my intentions were positive and I added a bounty to try to solve this real problem. It saddens me to even see downvotes for the answers although they made an effort to help.
EDIT: I'm unable to delete this question it seems. I get an error message.
EDIT2: In case it's more helpful, here's a spectrum analysis of both sounds using Audacity. There are lots of different options, but this is using the default options for Analyze->Plot spectrum
This question is not at the right place (and down-voted) but for your information you may take a look on Frequency Range of Dog Hearing where you can read that:
Humans can hear sounds approximately within the frequencies of 20 Hz and 20,000 Hz
[...]
The frequency range of dog hearing is approximately 40 Hz to 60,000 Hz
Note also that:
The shape of a dog's ear also helps it hear more proficiently.
A similar example is :
A vacuum cleaner, which merely sounds loud to us, can produce a high frequency sound which may scare dogs away
I expect that very low frequency can also scare dog (like thunderstorm sound)
You may use a spectrum analyser software (open source audio-software like Audacity allow you to do the job) to double check if low/high frequency are present in the sound.
In my opinion you may use a Band-pass filter, to cut all frequency lower than 50KHz & higher than 15KHz to avoid the "the vacuum cleaner" and "thunderstorm sound" effect (which may scare dogs.)
You may finally take a look on the Audacity low pass filter manual to know how to apply this filter on your sound.
Despite the fact that the question is offtopic here, I'll move here my initial answer from comments - I guess this will allow the question author to close question bounty properly.
The answer:
1. I guess your question is downvoted because here's a place for computer software and hardware functioning related questions, and your question is rather from physics or biology domains. So ask them on appropriate SO sections: physics.stackexchange.com and/or biology.stackexchange.com
Regarding your question, I would recommend you to check your sounds frequency range: dogs do not like sounds with loud high frequencies. Perhaps your sounds contains high frequencies, you can check it yourself with sound spectrum diagram in some audio redactor, for example Audacity
And yes, as #astefani pointed out those frequencies can be removed with band-pass filter, for example with low-pass filter in Audacity
I'm trying to interface a Nexys3 board with a VmodTFT via a VHDCI connector. I am pretty new to FPGA design, and although I have experience with micro-controllers. I am trying to approach the whole problem as a FSM. However, I've been stuck on this for quite some time now. What signals constitute my power up sequence? When do I start sampling data? I've looked at the relevant datasheets and they don't make things very clearer. Any help would be greatly appreciated (P.S : I use Verilog for the design).
EDIT:
Sorry for the vagueness of my question. Here's specifically what I am looking at.
For starters, I am going to overlook the touch module. I want to look at the whole setup as a FSM. I am assuming the following states:
1. Setup connection or handshake signals
2. Switch on the LCD
3. Receive pixel data
4. Display video
5. Power off the LCD
Would this be a reasonable FSM? My main concerns are with interpreting the signals. Table 5 in the VmodTFT_rm manual shows a list of signals; however, I am having trouble understanding what signals are for what (This is my first time with display modules). I am going to assume everything prefixed with TFT_ is for the display and everything with TP_ is for the touch panel (Please correct me if I'm wrong). So what signals would I be changing in each state and what would act as inputs?
Now what changes should I make to accommodate the touch panel too?
I understand I am probably asking for too much, but I would greatly appreciate a push in the right direction as I am pretty stuck with this for a long time.
Your question could be filled out a little better, it's not clear exactly what's giving you trouble.
I see two relevant docs online (you may have seen these):
Schematic: https://digilentinc.com/Data/Products/VMOD-TFT/VmodTFT_sch.pdf
User Guide: https://digilentinc.com/Data/Products/VMOD-TFT/VmodTFT_rm.pdf
The user guide explains what signals are part of the Power up sequence
you must wait between 0.5ms and 100ms after driving TFT-EN before you can drive DE and the pixel bus
You must wait 0 to 200ms after setting up valid pixel data to enable the display (with DISP)
You must wait 160ms after enabling DISP before you start pulsing LED-EN (PWM controls the backlight)
Admittedly the documentation doesn't look great and some of the signals names are not consistent, but I think you can figure it out from there.
After looking at the user guide to understand what the signals do, look at the schematic to find the mapping between the signal names and the VHDCI pinout. Then when you connect the VHDCI pinout to your FPGA, look at your FPGA's manual to find mapping between pins on the VHDCI connector and balls of the FPGA, and then you can use the fpga's configuration settings to map an FPGA ball to a logical verilog input to your top module.
Hope that clears things up a bit, but please clarify your question about what you don't understand.
I am looking for some advice on categorizing a library of sound effects. I have a large set of random sound effects, (think whistles, pops, growls, creaks, gunshots etc). I would like to be able to take a growl for example, and find the next growl that sounds the closest to the original.
Given a sound, what sound from my set sounds the closest to it.
I have done a fair amount of googling and have found two avenues that I am still researching. One is using echonest, although their "best match" support looks not promising for public users. The other option is diving into FFT and building my own matching algorithm. This is a fine option and would be a great learning experience but I wanted to get some opinions from others who might know a little more about sound processing; especially short clips .5sec - 3sec range, not full length music.
Thanks!
I have worked in movie postproduction for years and as far as I know, there is no way to do that automatically. Every file has meta information in its file header which describes what the sound is like. You are then actually not searching for the file names but in the meta string.
I don't think that it is trivial to sort effects programmatically as two effects that sound similar might be totally different if you look at the waveform.
You would need to extract significant information about a sound that you can then compare.
I am also not a DSP expert, maybe there are methods to do this
If you're interested in trying to build your own system to do this, I can suggest a few keywords that might help to refine your Google searches. In the academic research community, the task you're describing is often called "content-based audio searching". I know there's been a lot of work done on it, and though most pertains to music, sound effects have definitely been the focus of a number of studies.
You might want to start with the work of Pedro Cano.
Also, I recently heard about a company that's doing similar work. You might want to check out products from Imagine Research.
Those are just a couple of ideas off the top of my head. I'm not %100 sure they'll be helpful. If they are, please let me know!
Good day,
I am working on a Stratix III FPGA which contains M9K block memories, the contents of which are conveniently initialised to zero on power-on. This suits my application very well.
Is there a way to reset the contents back to zero without power-cycling/reflashing/etc the FPGA? There seems to be no such option in the megawizard plugin manager, and I would like to avoid wasting a bunch of logic which just goes and sequentially writes zero to every address...
I have looked around and there is no reference to such a mechanism, but I thought I'd ask just in case someone knew a handy trick :] By the way I'm working in VHDL but I should be able to translate any Verilog.
Datasheet (does not contain the answer!) : http://www.altera.com/literature/hb/stx3/stx3_siii51004.pdf
Thanks in advance,
- Thomas
PS: This be my first post here, so if I've violated any etiquette please let me know :)
Sorry, the conventional ways to do that are:
to re-configure the fpga (you could trigger that from within your hardware if you don;t mind the whole thing "disappearing" while it reconfigures)
explicitly write zeros in (as you already suggested)
At the wackier end of the solution space, I guess you could also wire something up to the JTAG port if you already have a microcontroller either in the FPGA or outside - you might be able to overwrite the RAM contents that way too.
Imagine the radio of a car, does the electro magnetic fields through which the car goes through, have interference in the processing? It's easy to understand that a strong field can corrupt data. But what about the data under processment? Can it also be changed?
If so how could you protect your code against this? (without electrial protections just code ones)
For the most robust mission critical systems you use multiple processors and compare results. This is what we did with aircraft auto pilot (autolanding). We had three autopilots, one flying the aircraft and two check that one. If any one of the three disagreed, it was shut down.
You're referring to what Wikipedia calls soft errors. The traditional, industry-accepted work-around for this is through redundancy, as Jim C and fmsf noted.
Several years ago, our repair department's analysis showed an unacceptable number of returned units with single-bit errors in the battery-backed SRAM that held the firmware. Despite our efforts at root-cause analysis, we were unable to explain the source of the problem. At that point a hardware change was out of the question, so we needed a software-only solution to treat the symptom.
We wanted a reliable fix that we could implement simply and quickly, so we generated parity checks on blocks of code in the SRAM. We chose a block size that required very little additional storage for the parity data, yet provided enough redundancy to detect and correct any of the errors we'd seen and then some. It logs the errors it detects and indicates whether it can correct them, so we still know when bit errors occur in the field. So far, so good!
Our product manager did some additional research out of curiosity and convinced himself that the culprit was cosmic radiation. We never proved it unequivocally, but he was satisfied that the number of errors seemed to agree with what would be expected based on the data he found. I'm just glad the returns have stopped.
I doubt you can.
Code that is changed won't run, so likely your program(s) will crash if you have this problem.
This is a hardware problem.