I'm doing a competition that requires our device to pause and stop midway on a pole. The device carries an increasing load (chain). The midway point is marked with a slight score mark (which we don't believe will be that noticeable). The device is supposed to travel up on the outside of the pole without pausing, pause on the way down and again on the way up, not pause going down the second time and then stop midway going up again.
I don't have experience with programming sensors and motors so, while I have ideas about how to do this, I don't quite know how to actually program this. There's a cap on the top I can use to switch direction of travel but the end of the pipe is open. I'm thinking of using either height off the floor or the weight of the chain as a constant to mark position along the pole. I'm having trouble finding inexpensive sensors so I don't have specifics.
Right now, I'm toying with the idea of using the switch at the top as sort of an on/off for the pausing/not pausing code. Alternatively, I can use the constant measurement (height/weight) to count the cycles and switch on the code that way. Is this an effective way of doing this? I'm looking at a raspberry pi to control everything.
Related
I have a signal that checks if the data is available in memory block and does some computation/logic (Which is irrelevant).
I want a signal called "START_SIG" to go high X-time (nanoseconds) before the first rising edge of the clock cycle that is at 10 MHz Frequency. This only goes high if it detects there is data available and does further computation as needed.
Now, how can this be done? Also, I cannot set a delay since this must be RTL Verilog. Therefore, it must be synthensizable on an FPGA (Artix7 Series).
Any suggestions?
I suspect an XY problem, if start sig is produced by logic in the same clock domain as your processing then timing will likely be met without any work on your part (10MHz is dead slow in FPGA terms), but if you really needed to do something like this there are a few ways (But seriously you are doing it wrong!).
FPGA logic is usually synchronous to one or more clocks,generally needing vernier control within a clock period is a sign of doing it wrong.
Use a {PLL/MCM/Whatever} to generate two clocks, one dead slow at 10Mhz, and something much faster, then count the fast one from the previous edge of the 10MHz clock to get your timing.
Use an MCMPLL or such (platform dependent) to generate two 10Mhz clocks with a small phase shift, then gate one of em.
Use a long line of inverter pairs (attribute KEEP (VHDL But verilog will have something similar) will be your friend), calibrate against your known clock periodically (it will drift with temperature, day of the week and sign of the zodiac), this is neat for things like time to digital converters, possibly combined with option two for fine trimming. Shades of ring oscs about this one, but whatever works.
I'm trying to debug a laggy machine vision camera by writing text timestamps to a terminal window and then observing how long it takes for the camera to 'detect' the screen change. My monitor has a 60hz refresh rate, so the screen is updated every ~17ms. Is there a way to determine at what point within that 17ms window the refresh timer currently is for an X11 application.
EDIT: After wrestling with the problem for nearly a day, I think the real question I should have asked was how to generate a visual signal that was sufficiently fast to test the camera images. My working hypothesis was that the camera was buffering frames before transmitting them, as the video stream seemed to lag behind other synchronised digital events (in this case, output signals to a robotic controller)
'xrefresh' is a tool which can trigger a refresh event on an X server. It does this by painting a global window of a specified color and then removing it, causing all subsequent windows to repaint. Even with this, I was still getting very inconsistent results when trying to correlate the captured frames against the monitor output, no matter what I tried to do, the video stream seemed to lag behind what I expected the monitor state to be. This could mean that either the camera was slow to capture or the monitor was slow to update. Fortunately, I eventually hit upon the idea of using the keyboard leds to verify the synchronicity of the camera frames. ('xset led' and 'xset -led'). This showed me immediately that in fact my computer monitor was slow to update, instead of the camera lagging behind.
I am developing a digital delay on a microcontroller and I am stuck with the delay decay. The delay is implemented with a comb filter.
Here it is: http://www.tonmeister.ca/main/textbook/intro_to_sound_recording837x.png
The delay line, "emulating the tape", is implemented as a circula buffer. The effect can be killed and such case does not represents an issue; when turning the effect off though, I have the tail of the delay left in the buffer to process, as if the delay had been frozen and the tail slowly decay (depending on the feedback gain).
My question is: how many times I have to recirculate samples through the buffer?
One way I thought to approach this could be by modelling the physical process ... assuming that the input sequence has a loudness of 0dB for its entire duration and that, after going through the delay line, it gets attenuated by a factor of 1/10. In terms of loudness this corresponds to a drop of 20dB, as power = voltage^2, every time the sequence goes through the feedback path. The weakest audible sound has a loudness of −130dB but, taking into consideration the ambient noise as well, −120dB will be sufficient as the least reference power. Hence, after the echoes have been through the feedback path 6 times (120dB/20dB) they will be no longer audible.
Is there a more efficient way?
Thank you!
I'm using a Virtex 5 FPGA and want to have a few +5/0 I/O pins to communicate with a microcontroller. The only peripherials I've used on the board so far are pushbuttons and switches and no one I've asked seems to know the simplest way to do this I/O. I've looked around the board specification but haven't found any simple way of doing it. I would appreciate any advice you might have.
This is not an easy thing to do. If you don't have the schematic of the board, then you need to get volt meter with some fine pitch probes and reverse engineer the board.
It is pretty easy if you have 2 boards, with one board it can be really hard since the BGA signals may not be connected to a via and therefore not available on the bottom of the board, and even if they are, then you don't know exactly which pin they are connected to. But with some luck, you can find them since the VIA can only be connected to 4 possible pins surrounding it!
The first thing you need to do is to identify your chip, find the BGA print of the IC from Xilin'x web site.
If your board has some buttons already, then if you are lucky, those signals may be routed to the pins of the FPGA that are available on the bottom of your board. Here are the things you need to do:
Make sure you have good ESD protection to perform these test
Put your voltmeter into 'buzzer' mode
Check the pins of your connector and find out how it is connected, see if there is a pull-up and/or pull-down resistors on the board
when you find the 'active' pin of your connector, start connecting the other probe to the VIAs one by one
When you hear a buzz, make a note of the position (guess or measure the distance between the side of t he IC and the location of the via)
Identify the 4 possible pins that the signal can be connected to
Write a code to get all those 4 signals and connect them to ChipScope
In Chip Scope, capture all 4 signals and see which one is the one with the right connection!
alternative, you can create a design with inputs only, capture all the inputs and put them into a memory block and create a trigger logic to capture all the signals whenever any of the inputs changes, after lots of work and analysis, you will find the correct pins.
Anyway, these are just crazy ideas since this is a really difficult thing to do without having the PCB info of the board.
Good luck with your hacking.
I am working on a system with laser trip detectors(if something breaks the laser path I get a one on the output of the laser receiver).
I have many of these trip detectors and I want to detect if one is malfunctioning, but I do not know how to go about doing this. The lasers should not trip all that often..maybe a few times a day.
A typical case would be that the laser gets tripped for a .5-2 seconds, or brief intermittent tripping for a short time period, and possibly again after that(within 2-10 seconds)...
Are there any good ways to check the sensor is malfunctioning using a good statistical methodology?
You could just create a "profile" which includes the avg/mean/min/max of how often each sensor is tripped/how long it is tripped/how long is the time between a trip and the next trip etc. for example by using the data of some period of time like the last week/month or similar...
THEN you can compare the current state of a sensor to its profile... when the deviation is "big enough" you can assume an exceptional situation/perhaps a malfunction... the hardest part is to adjust the threshold for the deviation from the profile which in turn if hit triggers for example "malfunction handling"...