Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Reed Switch ok for high accuracy?


  • Please log in to reply
24 replies to this topic

#1 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 24 August 2011 - 05:52 PM

Hi,

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

Posted Image

Here is some info from http://reed-switch-info.com

Posted Image

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?

Cheers,

Paul
P.S. I have a hall effect sensor on the way

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 25 August 2011 - 08:06 AM

I gather you are using a timer in mode 3 perhaps? What scan rate are you using and is the jitter sample-to-sample or over time? Can you post a short list of typical values that shows the jitter? If you put in a test signal of some sort rather than the reed switch signal does the problem go away?

#3 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 25 August 2011 - 04:01 PM

Hi, I think it is the reed switch - I will try the hall effect over the weekend. Below is what I see with a lathe at constant speed, I have tried sampling at 100Hz and 1000Hz but get the same result - since I am not expecting more than 20 triggers a second 100Hz should be enough. Below: Backlog - number from labjack so I know I haven't missed anything Scan = a count of scan requests (so I know I don't miss anything) Channel = the the channel slot that the data appeared in with a single scan (I only output text on data found) MSW and LSW = timer data total ms = is a sum of all timer values sys ms = is a system time recording diff = tis the difference between system time and labjack timer time (this should roughly stay around the same value km/hr is the calculated speed from timer [codebox] backlog scan channel MSW LSW total ms sys ms diff km/h 0 86 90 1 23406 19.9275 9 10.9275 55.0471 0 87 42 1 23356 20.0164 9 11.0164 55.0781 0 87 220 1 23336 20.1053 9 11.1053 55.0905 0 89 24 1 23310 20.1941 9 11.1941 55.1066 0 89 202 1 23247 20.2829 9 11.2829 55.1457 0 90 154 1 23245 20.3717 9 11.3717 55.1469 0 91 106 1 23230 20.4605 10 10.4605 55.1563 0 92 58 1 23255 20.5493 10 10.5493 55.1407 0 93 12 1 23181 20.638 10 10.638 55.1867 0 93 190 1 23175 20.7267 10 10.7267 55.1904 0 94 140 1 23141 20.8154 10 10.8154 55.2116 0 95 94 1 23153 20.9041 10 10.9041 55.2041 0 96 46 1 23151 20.9927 10 10.9927 55.2054 0 96 222 1 23100 21.0814 10 11.0814 55.2371 0 97 176 1 23126 21.17 10 11.17 55.221 0 98 128 1 23049 21.2586 10 11.2586 55.269 0 99 154 1 23090 21.3473 10 11.3473 55.2434 0 100 108 1 23051 21.4358 11 10.4358 55.2677 0 101 58 1 23065 21.5244 11 10.5244 55.259 0 102 12 1 23024 21.613 11 10.613 55.2846 0 102 190 0 24485 21.6375 11 10.6375 199.959 0 103 140 2 21597 21.7902 11 10.7902 32.0694 0 104 94 1 22996 21.8787 11 10.8787 55.302 0 105 44 1 23041 21.9673 11 10.9673 55.2739 [/codebox] Here's how I configure the timer. One thing I noted in the example was the a counter was disabled - should I need to do this? [codebox] // Use the 48 MHz timer clock base with divider. Call(m_pAddRequest (lngHandle, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_BASE, LJ_tc48MHZ_DIV, 0, 0), __LINE__); // Set the divisor to 48 so the actual timer clock is 1 MHz. Call(m_pAddRequest (lngHandle, LJ_ioPUT_CONFIG, LJ_chTIMER_CLOCK_DIVISOR, 48, 0, 0), __LINE__); // Set the timer/counter pin offset to FIO4, which will put the first Call(m_pAddRequest (lngHandle, LJ_ioPUT_CONFIG, LJ_chTIMER_COUNTER_PIN_OFFSET, 4, 0, 0), __LINE__); // Enable both timers.// TODO - 1 or 2? this should probably only one until we need the other Call(m_pAddRequest (lngHandle, LJ_ioPUT_CONFIG, LJ_chNUMBER_TIMERS_ENABLED, 1, 0, 0), __LINE__); // Enable timer 32-bit falling to falling edge measurement Call(m_pAddRequest (lngHandle, LJ_ioPUT_TIMER_MODE, 0, LJ_tmFALLINGEDGES32, 0, 0), __LINE__);[/codebox] Thanks for your help! Oh - I don't have a reliable pulse generator :( Paul

#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 26 August 2011 - 07:24 AM

Can you describe what in your data is showing the problem? If you want to test your code with a good signal, enable another timer in PWM or FreqOut mode to create a test signal that you wire into the other timer.

#5 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 03 September 2011 - 03:43 AM

ok - haven't been ignoring you :) I have been working hard on this issue...

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

Posted Image

Which seems to have a pretty good squarewave

Posted Image

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

Posted Image

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.

Posted Image

Any ideas what to look for?

Cheers,

Paul

#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 06 September 2011 - 01:03 PM

1&2) I think these are the roll problem mentioned in Section 3.2.1:

http://labjack.com/s...ers-guide/3.2.1

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:

http://labjack.com/s...s-guide/2.9.1.7

#7 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 08 September 2011 - 03:57 PM

Hi

"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 Image

#8 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 09 September 2011 - 09:20 AM

Will post more on these other issues, but on a side note about your item 3 in post #5, I believe that could be the limit of the U3 clock. We did a bunch of tests with ideal signals and found that the U6 and UE9 basically read perfect (+/-1 count of error), but the U3 has jitter of around 0.5%. The U3 clock is RC based rather than crystal based and is rated for 1.5% accuracy (15000 ppm) compared to 30 ppm on the U6/UE9. I expected the short-term jitter to be much less than 1.5%, but in testing we did we found that the jitter was about 0.5% (3x better) over about 30 seconds. One strange thing is your sine shape. We just see random jitter, not a sine.

#9 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 09 September 2011 - 10:06 AM

I did a quick test using the LabView "U3 Stream AIN with Timers & Counters.vi" example. I set the clock to 1MHz/20, Timer0 RISINGEDGES16, Timer1 FREQOUT with a value of 255. Jumpered FIO4 to FIO5. And I got 510 for over 1,000,000 samples. I can provide this source code if it is useful to you.

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:
UDriver: 3.28
Firmare: 1.38

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.

#10 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 10 September 2011 - 03:05 AM

Hi and Thanks, I have now worked it out :rolleyes: Firstly, in the table "channel" should be "channel result number", it is the index into the scan array where the data is found (sorry confusing name). I am requesting 1000 samples a second of the Timer MSW and LSW (even in 16 bit I left the coloumn in). So you can see that I am getting some data every ~20th entry in each array. So the data is in the right spot just wrong. Now I know that yours works I persisted further. I first excluded Qt with the code attached (it's a mess sorry) and still got the errors. I then played about with the time delay between streams reads, and sure enough if I increased the time between reads the error disappeared! So the issue is that the LabJack can't handle reading the stream too quickly. If I read it 10 times a second, I get errors. If I read it at 1 times a second the errors go away. The reason I was trying for 10 times a second was to update a display in realtime, however I can live with less framerate. The U3 clock error though is of concern as it may throw out my dyno calculations. I'll see how I go and save up for a U6 in the meantime. Thanks! Paul

Attached Files



#11 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 12 September 2011 - 11:44 AM

I modified the LabView example mentioned earlier to read at 10Hz and 50Hz both situations seemed to work.

#12 pmcintosh

pmcintosh
  • Members
  • 26 posts

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!

#13 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 28 September 2011 - 12:47 PM

We finally reproduced this. I missed an important detail in your problem statement. Turns out that the issue only occurs when using the channel that also resets the timer. I was using the normal timer read.

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.

#14 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 29 September 2011 - 08:44 PM

Fantastic!!!!!!!!!!!!!!!!!!!!!!

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!

Posted Image

I am still saving up for a U6 but this solves a lot of my issues! Thank you!

#15 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 28 November 2011 - 04:17 PM

OK - not quite there yet :huh:

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?

MSW LSW
0 48403
0 48357
0 48368
0 48329
0 48263
0 48278
0 48269
0 48312
0 48368
0 48323
0 26945
1 4268
0 48332
0 48375
0 48339
0 48325
65535 64505
1 32031
0 48197
0 48193
0 48255
0 48268
0 48275

Posted Image

Cheers,

Paul

#16 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 28 November 2011 - 04:58 PM

There is a beta for the U6. http://labjack.com/s...irmware/u6/beta

Give that a shot and let me know how it goes.

#17 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 29 November 2011 - 03:25 PM

It is a bit better but I am still getting errors. Before I got a glitch ~10 readings, with the beta driver is about every ~20. Over the weekend I might try an record the same signal at the same time with the U3 and U6 and see what the difference is. MSW LSW 0 50560 65535 64082* 1 37397* 0 50781 0 50646 0 50639 0 50548 0 50512 0 50536 0 50587 0 50586 0 50574 0 50633 0 50520 0 50563 0 50608 0 50524 0 50512 0 50509 0 50485 0 50401 0 50542 0 50519 0 50572 0 14918* 1 20620* 0 50441 0 50382 0 50518 0 50457 0 39726* 0 61380* Cheers, Paul

#18 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 29 November 2011 - 05:02 PM

Well darn. U6 FW 1.32 has the same fix as the U3. I'll have to set up a test and try to reproduce what you are seeing.

#19 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 30 November 2011 - 11:15 AM

Turns out that the U6 did not have some of the changes. 1.35 seems to work better: http://labjack.com/s...irmware/u6/beta

#20 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 30 November 2011 - 02:59 PM

Thanks for the quick response! I tried it out on the way to work this morning and it is a lot better. However it seems to get into a mode where the LSW is not correct. I have attached a spreadsheet - it does 5500 readings perfectly, then the next 1000 look like the following, then the next 6000+ are OK. This could be noise on the sensor line? Looking at the first glitch 833 + 49725 = 50558 which looks right, so maybe something electrical is inducing an extra read... by your "better" does that imply you saw some glitches still? I can test on the weekend with the signal generator and rule out the LabJack as the problem. MSW LSW 0 50476 0 50198 0 50726 0 50970 0 50473 0 833 * 0 49725 0 50432 0 2022 0 48466 0 50496 0 50372 0 50378 0 50360 0 50316 0 1577 * 0 48626 0 50411 0 50201 0 50017 0 50365 0 50016 0 130 * 0 373 * 0 47368 0 49889 0 2342 * 0 47569 0 2440 * 0 47326 0 2723 * 0 47172 0 50038 0 49946 0 2512 * 0 47363 0 49904 0 49836 0 49818 Thanks! Paul

#21 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 30 November 2011 - 11:36 PM

The ride home was a lot better - no errors at all :) Thanks Again! Paul

#22 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 08 December 2011 - 03:20 AM

ok after the stream error tangent - I am now back to the original question on this thread...

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.

Posted Image

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?

Cheers,

Paul

#23 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 08 December 2011 - 08:55 AM

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.

#24 pmcintosh

pmcintosh
  • Members
  • 26 posts

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.

Posted Image

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.

Paul

#25 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 08 December 2011 - 04:52 PM

So I think you are streaming a Timer in 32-bit period input mode. You stream the data at 1000 scans/second using channel #230 so you can pick out the readings with new data. In your plot you are getting readings about every 47ms. Across the 20 readings in your plot (about 1 second) there appears to be a slight acceleration (47.45ms to 47.25ms) which might be OK, but reading-to-reading there are jumps of up to ~100us which you do not feel are valid. Because of your latest test with a test signal from your scope, you have confidence that the U6 is reading correctly, so that suggests the signal really has these jumps. One possibility is that the signal would have these jumps even if the sensor was perfect. Perhaps there is a vibration or something that causes this. Seems to me that this is quite possible. The other possibility is that the sensor (reed switch) is not consistent enough in its response and that is causing the jumps. Depending on the speed of response you want from your measurements, you could implement a filter such as: FilteredReading = 0.9*FilteredReading + 0.1*NewReading Assume your reading has been 10 for a long time. Then FilteredReading would be 10.0. If the measurements suddenly change to 0.0, it would take 10 iterations before the FilteredReading goes to 0.0.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users