Reed Switch ok for high accuracy?
Posted 24 August 2011 - 05:52 PM
I have been using a reed switch to measure wheel rotation. I am using a U3 streaming with a 32 bit timer at 1MHz and I this gives me 1 us accuracy. However I am seeing the reading wandering even at constant speeds. The readings are within 0.1% of what is expected however even that is throwing out my calculations as it is not a consent error (i.e. one reading will be +0.1% and the next -0.1%).
I am thinking that the reed switch is not giving a consistent reading.
Here is my debounced signal and I am reading off the falling edge
Here is some info from http://reed-switch-info.com
I am not sure if the graph is intended to show variations (it could be an artefact of the animation) but if the output initial edge jumps around that much then that is the cause of my issue.
I am just wondering if my thinking is right? Or maybe my falling edge is still not clean enough? Has anyone else got down to 1-2 us second accuracy with a reed switch?
P.S. I have a hall effect sensor on the way
Posted 25 August 2011 - 08:06 AM
Posted 25 August 2011 - 04:01 PM
Posted 26 August 2011 - 07:24 AM
Posted 03 September 2011 - 03:43 AM
First I tried to use the Labjack to generate a pulse but for some reason couldn't get it to work as needed - I gave up because I assume that it I am using timer0 for period measurement, I am locked into a frequency for a pulse.
Anyway... I went out and bought a signal generator
Which seems to have a pretty good squarewave
So I have excluded the reed switch and debounce circuit from the equation. I drove the LabJack with a constant frequency for a bit and then ramped it up to higher frequency for a bit. In theory I should see 2 straight lines and a transition period between them. I still see 3 problems in the data (here is an excel spreadsheet) Numbers are in km/hr based on rpm and 1360mm wheel circumference.
1) The readings hickup every so often, it's like the LabJack misses a beat, catches one reading very late and makes up for it in the next
2) Occasionally the hickup is really bad and it is like the MSW contains garbage. Skim down the MSW coloumn in the spreadsheet and you will see a few instances where the MSW is "65535" (suspicous that it is the same value)
3) Even for non-hickup sections, the readings drift, I see this with the reed switch but the reed switch is erratic. Below is what I see with the signal generator. Now it could be the generator as it suspicious that it is pretty smooth. I would be interested to know if you have done this test yourself with a new signal generator.
Any ideas what to look for?
Posted 06 September 2011 - 01:03 PM
I am going to change the language in that relevant paragraph to recommend against using modes 2 or 3 in stream. We will look at firmware and see if there is a way to handle this, but as of now the 32-bit mode should really just not be used when streaming.
How about using the 16-bit mode instead? You might need to reduce your timer clock a little so the 16-bit timer does not roll at the slowest frequencies you want to measure.
3) I will try a test like this.
To test with a signal from the U3 itself, just change # of timers enabled to 2, then add a request to set the mode to LJ_tmFREQOUT and add a request to set the value as desired:
Posted 08 September 2011 - 03:57 PM
"It is not recommended to stream timers configured in mode 2 or 3 (32-bit period measurement). It is possible for the LSW to roll, but the MSW be captured before it is incremented. That means that only the LSW is reliable, and thus you might as well just use the 16-bit modes."
I think that might explain "2" but for "1" both the LSW and MSW are out.
16 bit timers will be hard as I have a wheel that is spinning at between 1Hz and 44Hz and want to maintain high accuracy.
I did try 16 bit timers with the signal generator and got the same result!? Every so often the data would jump.
I then tried it again with the LabJack freqout (@FIO5) as suggested and again the numbers jump! So I think the issue is with the streaming timers or maybe my LabJack has issues? If I use the LJControl test I see a constant "510" but I gather the LJControl test is polling. Did you try your test? Did it work? Could I try the code myself?
Below is what I see with a 1Mz clock / 20 and a freqout / 255. I have a scan rate of 1000Hz and I am reading the stream every 100ms.
Posted 09 September 2011 - 09:20 AM
Posted 09 September 2011 - 10:06 AM
The same test with LJStreamUD also seemed to work properly. You can get LJStreamUD here: http://labjack.com/s...t/ud/ljstreamud. I used "config io defaults" in LJControlPanel, then power-cycled to enable the timers and then used the example application to stream the value, again 510 was the only value returned.
Software versions I used:
I still don't understand the table in your previous post. Why would you be streaming channels 162, 182, and 202, those and the majority of the numbers I see in the channels list are invalid channels on the U3.
Posted 10 September 2011 - 03:05 AM
Posted 12 September 2011 - 11:44 AM
Posted 22 September 2011 - 04:29 AM
I modified the LabView example mentioned earlier to read at 10Hz and 50Hz both situations seemed to work.
Had a bit of a break from it - tried again...
It seems to be intermittent and more like a funny state the LabJack gets into when it starts up. I set it to 100Hz and it reads fine but as I try different things I get the odd occasion when repetitive errors appear. I tried ramping down the time, from 2Hz -> as fast as possible, to see if it was something to do with that, but that didn't trigger yje problem.
I'll carry on, maybe it is just a matter of doing a full reset each time I start.
Thanks for your help!
Posted 28 September 2011 - 12:47 PM
It turned out that there were two different problems, one zeroing out the lower byte and one setting the upper byte to 65535. Both have been fixed in beta 1.41: http://labjack.com/s...irmware/u3/beta
This problem was difficult to observe in the firmware, so I had to reason my way though the fix. Firmware 1.41 has not generated either error in over 1700 stream cycles so I think that it is fixed. There is some chance that I missed something, so let us know how it goes for you.
Posted 29 September 2011 - 08:44 PM
I did a test this morning riding to work with the new firmware and only got one glitch in ~14,000 reads of real data. The glitch is the spike near the start of the plot is probably unrelated to the Labjack. So it appears to be 100% fixed!
I am still saving up for a U6 but this solves a lot of my issues! Thank you!
Posted 28 November 2011 - 04:17 PM
I upgraded to a U6 as I really needed the more accurate timing measurements. I am using the exact same code, just set to FIO0 and looking for a U6. Now I am seeing the glitch again - below is the readings I get from the stream and it graphed with the Vespa going a constant 100km/hr. Does this mean the U3 bug exists in the U6 firmware - is there a beta version with a fix?
Posted 29 November 2011 - 03:25 PM
Posted 29 November 2011 - 05:02 PM
Posted 30 November 2011 - 02:59 PM
Posted 30 November 2011 - 11:36 PM
Posted 08 December 2011 - 03:20 AM
Firstly, the signal generator I used for testing is a dud. That was introducing the wandering readings (these were a secondary problem to the glitches). I did another test with a test signal from my digital scope and the U6 aced the readings every time +/- 1 accuracy (nice) and the U3 could not keep up (it was a high frequency signal compared to the scooter). So I am glad I got the U6.
However, even though the U6 is better than the U3, they both report about the same for the reed pickup. So the reed switch (or cables) is introducing way more error than the LabJack clock differences. Below is the normalised speed based on readings from a steady speed. The first reading is subtracted from all the others, so we see just error.
Even my dud signal generator is producing less error :(
So I would say that the reed switch is not OK for high accuracy. Is there a recommendation for a wheel rpm sensor that is high accuracy that is also fairly weather proof? Or am I pushing my luck and should just live with what I have and average the readings out?
Posted 08 December 2011 - 08:55 AM
Posted 08 December 2011 - 02:56 PM
As far as a different sensor I would lean towards anything solid-state over a reed switch. In addition to hall-effect, there are various IR/photoelectric options, and various inductive/magnetic prox sensors. I don't have anything particular to recommend, but check out Balluff and Automation Direct.
As for your varying data from the reed switch, we have discussed various things so can you detail again how you are getting this data and deciding it is inaccurate or varying.
Thanks I will check out the other options. As for variations this is what I see from the U6 LSW when travelling at a constant speed of 103km/hr. The reading is jumping up and down and I would expect it to be smooth. This is a typical example and I see some variations going to the point of suggesting that for 50ms I am accelerating with a force of 20hp (more power than the scooter has) and the next -20hp. HP is one if the things I am trying to measure and that is why these errors are throwing out my calculations.
As a side note - I was going to use this also for a Dyno that my friend has, he ended up buying a ready built system with an optical sensor. My friend asked him about read switches and was told "they are no good" - I didn't get more than that.
Thanks for your help - it has been a learning exercise and I will update the thread when I have the results from the next sensor I try.
Posted 08 December 2011 - 04:52 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users