I would like to hear all ideas on the project, and we may try few of them to see which one is better in detecting speed, cheaper, lower maintenance. So the door is wide open, the backup plan is using radar, but it is kind of expensive. the speed detector will be placed about 120M apart in the middle id the subway tunnel, each segment will have 5 or more th detect the speed of the train. The train is not running at constant speed, it either accelerate or decelerate, therefore the video frame will need to be adjust constantly. -- Youda On Thu, Oct 28, 2010 at 1:31 PM, Oli Glaser wrote= : > On 28/10/2010 20:44, Olin Lathrop wrote: >> Oli Glaser wrote: >>>> 2 - You still rely on knowing parameters of the train, which in this >>>> case is the spacing between wheels. >>> Of course, but I thought that part was rther obvious.. :-) >> But yet you suggested a method with this obvious drawback. > > It is not a drawback if the parameters are known. As I said before, it > depends on the situation. If there are standard parameters like these, > then they can be used to ones advantage. If not, then obviously you can > consider other options. > >>> Note the "something like" in my post - it depends a lot on what >>> information is available, and the situation (which I am mostly in the >>> dark about) >>> For instance, if all trains are a standard length, then it could be as >>> simple as timing the duration of the noise. >> Why go to great lengths to concoct a system that might sortof work if >> everything is right and only Standard Trains pass by, when much simpler = and >> reliable methods are readily available? > > I wasn't aware of any "great lengths" involved, and again it depends on > many things as to which methods will be the simplest/most reliable. > >>> plenty of ways to do this.. >> That's the point. =A0There are plenty of ways that can be dreamt up to d= o >> this, but not that many that are simple to implement, reliable, cheap, >> readily doable, and don't require the train to be just right. =A0As I >> understood the question, it was a practicle one, not a theoretical one. = =A0Do >> you really think futzing around with a DSP algorithm to detect the right >> sound, and then assuming a particular wheel spacing makes sense as a met= hod >> of getting the job done? =A0Do you really think that is quicker to imple= ment >> and tweak than a couple of magnetic sensors, and that it will work in mo= re >> circumstances and stay working in the real world longer? =A0Right, I did= n't >> think so. >> > > :-) > It was just an idea thrown into the pot, and the quickest and easiest > solution is liable to be whichever the OP is most comfortable with, and > fits with the situation best. > >> While it may be interesting from a theoretical point of view, it's frank= ly >> silly if you just want to solve the problem. =A0If you want to muse abou= t >> theoretical solutions, thats fine as long as you label them as such. =A0= Your >> message made it sound like you were seriously proposing this as a real >> solution, which is doing the OP a disservice. > > I was seriously propsing it as a suggestion. That's what the OP was > asking for, at least that's the impression I got. I personally think > that the more ideas thrown into the pot the better, even if some are a > bit more "out there" they may help trigger a useful idea, or be used in > combination to present a more effective solution. > I don't think I was doing anyone a "disservice", it was certainly not my > intention. If the Op feels differently I do apologise though, and will > try to refrain from having any further "ideas" or forgetting to label > them appropriately.. :-) > > > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .