I want to conduct an experiment which needs cheap Waterproof Ultrasonic sensor with the ability of accessing raw echo signal. However, perhaps I can't find such product in the market.
Currently, the sensor like JSN-SR04T is very popular, but it can only access the transmitting time of echo. The raw signal has been processed and I CAN'T get it.
Seems most companies just want to provide sensor with ranging ability not others, but my project highly rely on getting the raw data.
For your information, I know that Sonar may match my expectation, and I have already bought one. But the price is too expensive and I don't need such good one.
So I wonder if you guys know some sensor can achieve it? The worst case I have to hack the current circuit, it will cost too much unmeaningful time.
Edit:
Some company do provide solution, which is just have an analog output of the circuit. And I will update the performance later.
Related
I was wondering if I could get a cheap GPS tracking device such as this one on amazon and reprogram it to send the co-ordinates to my own server? I would then like to generate reports from the DB on my server based on dates etc. I would like to build this for a very small-scale courier company I am planning on starting.
I am an amateur/hobbyist programmer and am looking for a few pointers to help me get on the right track. Pun totally intended.
This is a very broad question. But since no one answered so far, I will just throw in my two cents. First of all, you need to know what GPS signal the (cheap) receiver can track. If it can track only single frequency at L1, there's not much you can do. You have to live with large ionosphere fluctuation error signal.
http://www.navipedia.net/index.php/Ionospheric_Delay
If it can only track code signal (not carrier phase signal) you cannot do code smoothing to reduced the noise level of code signal received.
In other words, if a GPS receiver hardware is limited, there's not much room for improvement.
As the question says ,I want to monitor the value of power(watts) that some components consumption .especially the value of CPU , Memory and disk .
when I use aida64，I found that in computer/sensor ,there are some data about power consumption . I want to know how did it can get these data ?
I already have some idea ,but not sure which is the best way to solve this question :
there are some sensors on the motherboard ,we can use values of those sensors to calculate the real-time power.
according to different OS, we have some APIs that can get the utilization of cpu,memory throughout rate and disk I/O rate . Using this data ,we can build mode of power consumption about PC.if there are those APIs,where can I find them ?
maybe the hardware manufacturer like intel has already record the value of power in real-time ,they put the value into some special register in hardware .we can get the value through mapping into special memory location .
In my opinion ,the second way maybe the solution that most monitor software using .but I just don't know where can I get those API.
whats more ,our aim is to design an OS-independent real-time power monitor software. So, if there are any better solutions about this question ,I will appreciate your help .
Hmmm. I wasn't sure if I should post this as a comment or an answer. It is an answer but in the negative.
At this time, you can't create an OS independent software-based non-intrusive power monitor. By non-intrusive, I mean that you are not putting special instrumentation on the motherboard and other hardware. This is because the power technology being used by modern processors is in rapid flux, each new generation making significant advances. Additionally, the amount of power related information available to software from the hardware (via PMU events and the like) is continually increasing as more silicon real estate becomes available. For example, I believe that in the most current processors, you can get direct thermal information for key parts of the processor silicon, and temperature, power and current readings from various parts of the core and uncore.
The best you can do is to abstract the top layer of your monitor from the lower layers. Then the top becomes OS / HW independent while the lower levels need to be platform dependent.
Check out the PAPI APIs. Note that the APIs appear to give you the world, but are really just an API set. Someone still has to implement what's on the other side of the API.
Now if you can do your own special instrumentation, many (most?) motherboards and other hardware have measurement points (some undocumented) that provide thermal, current (and so power) information. This information is important for debugging devices and platforms.
I'm looking for a GPS for a small class project. We want the smallest GPS possible and all we really need it to do is to give us longitude and latitude values when we poll it.
I tried looking at sparkfun, but since we haven't really worked with this type of hardware before, it's hard to know which kind we really want/what parts we need.
What We Need:
smallest possible
longest battery life
only need long and lat
able to be polled from some other device such as a mobile app or website
Thanks!
there are two paths to this, one is just get a bluetooth receiver, you will be able to poll it from a mobile phone or whatever. going to likely be as big as the phone, have the battery inside, etc. not sure how long it will last on one charge.
There are other solutions designed for putting in packages being shipped, better battery life, but their goal is as data loggers and not necessarily something you can cable up and poll and likely not wireless if that is what you are after.
Now if you want to build your own, and you already went to sparkfun, here is another path.
I know that leaving links in an answer at SO is bad...This was longer than a comment and will add some more info...
You want small you can go with this
https://www.sparkfun.com/products/11571
It is a GP-635T gps receiver, if you look at the picture it really is around the size of a quarter. 50 channel. Point it up the way they tell you, antenna is built in, just power it and it works.
You will need to hook up to it. It is the serial version not usb, in either case you need a cable like this.
https://www.sparkfun.com/products/10361
This link is to a cable with 6 or 8 inch pigtails, the gps receiver comes on a board with a not so uncommon connector on it, this cable allows you get at those connections, you only need three.
The datasheet on the sparkfun page or probably just search for the part number, you need to look at the UART TTL pinouts not the usb pinouts. Yo uneed 3.3 to 5.5volts to power it pin 2, pin 1 is ground. then pin 3 is txa serial out. This is where you get your data.
these are various solutions that will work
https://www.sparkfun.com/products/9873
https://www.sparkfun.com/products/718
http://jim.sh/ftx/
some soldering may be required. The above links are various solutions between $10 and $15 for ftdi usb to serial/uart break out boards. These will include 3.3v and ground and the rx pin is the receiver for the ftdi uart, you tie that to txa on the gps unit.
What you may not know and may be interested in is that almost universally gps units do their math magic and come up with the various items time, position (2d or 3d), speed, etc. And they output this data in a serial manner. search for NMEA or NMEA-0183. The data sheet for this and any other should give an indication of the default data rate (4800, 9600, 19200, etc baud) and what messages are sent. sometimes you can change the baud rate, sometimes you cant. The ftdi chips/boards are very flexible use a usb cable to plug in the board to a computer, configure your software or a dumb terminal program like minicom or hyperterm or teraterm or whatever (no parity, no hardware flow control) and the messages will appear usually once a second. Whether it is your car navigation, handheld gps, whatever, buried inside is some flavor of gps reciever (sparkfun will give you an indication of just how many different flavors there are and their selection is just scratching the surface) that outputs serial and the software in that unit is receiving that serial data and then doing its thing (mapping, navigating, etc). As with modems back in the day the ones you find in your cell phone might have some of the software/math done by the main processor in the phone to save on money, these libraries are not generally available, when you make the deal to buy thousands or millions of units they allow you to pay for the software to go with it along with your signature on a bunch of legal documents. I assume this is the case, that is how the ones in phones are down to $10 or so where these fully contained solutions are usually $50 to $100 in single quantities and likely not a lot cheaper in quantity.
Once powered, even if it says X number of seconds hot or cold to lock it doesnt always take that, sometimes if it has to search it may still take a while, the less metal you have around (like being in a building or the center of a car) the worse it is to the point it may not lock.
if you have an older garmin street pilot (that is otherwise dead I would hate to kill one of those if it is working) you can rip it apart and likely find a sirf III or other module in there, likely a 5V not 3.3 (there are 5V ftdi based breakout usb to serial. the microftx is both 5v and 3.3, note the gps receiver linked above is also 5v or 3.3) googling will be required to figure out the pinout and such, and soldering might or might not be a challenge.
you can also find old etrex or other handhelds on ebay or wherever (that work!) and for $15 or so get a serial cable, well then you need a serial to usb likely which will also need a level shifter like a max232, you dont plug this right into a ftdi break out board, it will fry it. newer ones have usb and you can power the unit from the usb and likely see the nmea data over the usb as well.
Most of the stuff you see on sparkfun in the gps area is going to be related to these various brands and models of gps recivers that output nmea data over serial. some are 5V some are 3.3, many do not have antennas and you have to buy those separately (and get the right kind, one that plugs into the connector provided, etc). I have a number of these items and they all work just fine, some do better than others around buildings or in trees, etc. Around sparkfun you will also find lipo battery solutions and bluetooth or xbee or other wireless solutions, very quickly if you need wireless, I think you will find just buying an off the shelf solution is best. I have had my eye on the garmin bluetooth thing google
Garmin GLO Portable GPS and GLONASS Receiver
it is about $99. I have not pulled the trigger yet so I dont know how good or bad it is, the el cheapo brands just look cheap.
Of course, a smart phone has both wireless and a gps and you can get a lot of used phones for cheap on ebay. Ios and android. You could "just write an android app" and put it on the phone and use one of the wireless interfaces built into the phone. It will chew through the battery yes, how fast? who knows.
How should I decide system requirements like:
RAM capacity
FLASH memory capacity
Processor frequency
etc
I am building an application to control NAND FLASH, LCD driver, UART control, keypad control using a 16 bit micro-controller.
This has to be estimated from previous projects with similar functionality. Or even other people's products. But it is best to develop with a larger capacity and decide on final parts when your software nears completion, because its easier to omit components than to try and find room for them later. This kind of design can be an iterative process, start with one estimate and see if a prototype works, don't commit to volumes until you are nearly at the end.
In the case of an LCD based product, you will have two major components using up flash memory, the code and the LCD data (character strings, bitmaps etc). Its certainly easier to estimate the LCD data than the code, which depends on functionality, compiler optimisations etc. If you are bringing in external libraries then at least you already have code for them.
In any case, have an upgrade plan. The worst thing is to run out of capacity at the end of the project and be struggling to optimise the last feature/debug solution in without adding another problem. Make sure you know what the next size up chips are and how you can get them to fit, sometimes a PCB can be designed to take various different chips in the same position. Or have an expandable system, where you can plug things into a memory bus.
How many units will you be making ?
If your volumes are low (<1e3), but per unit profits high and time to market matters, more hardware will get the developers done sooner.
If the volumes are huge (>1e6), profits per unit low, then you penny pinch the hardware, but time to develop will go up. If time to market matters, that's a tradeoff.
Design the board with 2x the capacity (RAM/flash), but don't load the parts, other than to check it works.
Then if you run out of room, there is somewhere to go.
Will customers expect to get firmware updates ? Or is this a drop-ship product with no support ? Supportable is harder, needs more resources.
You'll need to pad resources to have room to expand into if the product needs support for a long time.
For CPU frequency estimates, how much work is required to be done ?
Get an Eval board for a likely MCU and prove out the core function.
Let us say it's a display for a piece of exercise equipment. Can it keep up with the sensors on the device at 2-3x the designed pace ? That's reading the sensors and updating the display. If cost is required to be low, you can then underclock the eval board adn see what trades can be made.
I have an embedded device (Technologic TS-7800) that advertises real-time capabilities, but says nothing about 'hard' or 'soft'. While I wait for a response from the manufacturer, I figured it wouldn't hurt to test the system myself.
What are some established procedures to determine the 'hardness' of a particular device with respect to real time/deterministic behavior (latency and jitter)?
Being at college, I have access to some pretty neat hardware (good oscilloscopes and signal generators), so I don't think I'll run into any issues in terms of testing equipment, just expertise.
With that kind of equipment, it ought to be fairly easy to sync the o-scope to a steady clock, produce a spike each time the real-time system produces an output, an see how much that spike varies from center. The less the variation, the greater the hardness.
To clarify Bob's answer maybe:
Use the signal generator to generate a pulse at some varying frequency.
Random distribution across some range would be best.
use the signal generator (trigger signal) to start the scope.
the RTOS has to respond, do it thing and send an output pulse.
feed the RTOS output into input 2 of the scope.
get the scope to persist/collect mode.
get the scope to start on A , stop on B. if you can.
in an ideal workd, get it to measure the distribution for you. A LeCroy would.
Start with a much slower trace than you would expect. You need to be able to see slow outliers.
You'll be able to see the distribution.
Assuming a normal distribution the SD of the response time variation is the SOFTNESS.
(This won't really happen in practice, but if you don't get outliers it is reasonably useful. )
If there are outliers of large latency, then the RTOS is NOT very hard. Does not meet deadlines well. Unsuitable then it is for hard real time work.
Many RTOS-like things have a good left edge to the curve, sloping down like a 1/f curve.
Thats indicitive of combined jitters. The thing to look out for is spikes of slow response on the right end of the scope. Keep repeating the experiment with faster traces if there are no outliers to get a good image of the slope. Should be good for some speculative conclusion in your paper.
If for your application, say a delta of 1uS is okay, and you measure 0.5us, it's all cool.
Anyway, you can publish the results ( and probably in the publish sense, but certainly on the web.)
Link from this Question to the paper when you've written it.
Hard real-time has more to do with how your software works than the hardware on its own. When asking if something is hard real-time it must be applied to the complete system (Hardware, RTOS and application). This means hard or soft real-time is system design issues.
Under loading exceeding the specification even a hard real-time system will fail (hopefully with proper failure indication) while a soft real-time system with low loading would give hard real-time results. How much processing must happen in time and how much pre/post processing can be performed is the real key to hard/soft real-time.
In some real-time applications some data loss is not a failure it should just be below a certain level, again a system criteria.
You can generate inputs to the board and have a small application count them and check at what level data is going to be lost. But that gives you a rating specific to that system running that application. As soon as you start doing more processing your computational load increases and you now have a different hard real-time limit.
This board will running a bare bones scheduler will give great predictable hard real-time performance for most tasks.
Running a full RTOS with heavy computational load you probably only get soft real-time.
Edit after comment
The most efficient and easiest way I have used to measure my software's performance (assuming you use a schedular) is by using a free running hardware timer on the board and to time stamp my start and end of my cycle. Or if you run a full RTOS time stamp you acquisition and transition. Save your Max time and run a average on the values over a second. If your average is around 50% and you max is within 20% of your average you are OK. If not it is time to refactor your application. As your application grows the cycle time will grow. You can monitor the effect of all your software changes on your cycle time.
Another way is to use a hardware timer generate a cyclical interrupt. If you are in time reset the interrupt. If you miss the deadline you have interrupt handler signal a failure. This however will only give you a warning once your application is taking to long but it rely on hardware and interrupts so you can't miss.
These solutions also eliminate the requirement to hook up a scope to monitor the output since the time information can be displayed in any kind of terminal by a background task. If it is easy to monitor you will monitor it regularly avoiding solving the timing problems at the end but as soon as they are introduced.
Hope this helps
I have the same board here at work. It's a slightly-modified 2.6 Kernel, I believe... not the real-time version.
I don't know that I've read anything in the docs yet that indicates that it is meant for strict RTOS work.
I think that this is not a hard real-time device, since it runs no RTOS.
I understand being geek, but using oscilloscope to test a computer with ethernet/usb/other digital ports and HUGE internal state (RAM) is both ineffective and unreliable.
Instead of watching wave forms, you can connect any PC to the output port and run proper statistical analysis.
The established procedure (if the input signal is analog by nature) is to test system against several characteristic inputs - traditionally spikes, step functions and sine waves of different frequencies - and measure phase shift and variance for each input type. Worst case is then used in specifications of the system.
Again, if you are using standard ports, you can easily generate those on PC. If the input is truly analog, a separate DAC or simply a good sound card would be needed.
Now, that won't say anything about OS being real-time - it could be running vanilla Linux or even Win CE and still produce good and stable results in those tests if hardware is fast enough.
So, you need to simulate heavy and varying loads on processor, memory and all ports, let it heat and eat memory for a few hours, and then repeat tests. If latency stays constant, it's hard real-time. If it doesn't, under any load and input signal type, increase above acceptable limit, it's soft. Otherwise, it's advertisement.
P.S.: Implication is that even for critical systems you don't actually need hard real-time if you have hardware.