Actions
Forum Thread Details
  • Replies 22 replies
  • Subscribers 597 subscribers
  • Views 1506 views
  • Users 0 members are here
Related

400K Milestone

dougw

400K+ !

Congratulations on reaching into uncharted territory above 400,000 points.

There doesn't seem to be much fanfare for this milestone, but it is a monumental achievement nonetheless.

This sets a great example for other members to learn from and emulate.

Keep it up...

  • in reply to Andrew J

    Hi Andrew,

     

    I had a look at the code tonight, and made changes to the algorithm.

    Previously, it would count the number of transitions in one second, and that would be converted to frequency. It wasn't granular, since I only thought about the power tool use-case, where a few tens of RPM don't make a difference. It also made the code easy : )

    However, in your scenario, you need more accuracy and granularity! Unfortunately the chip that is used is limiting, because it was chosen to be a DIP chip, and it can only accept a 32.768kHz clock. This can get multiplied up in the chip, but it has an error, in my case I found it to be just over 1%, which is quite significant (but fortunately it can be mostly calibrated out, as explained below. I think there's also a way to calibrate the clock in the chip possibly, but I'm not super-familiar with that).

    For the new algorithm, it uses a multiplied-up 8MHz clock in the chip, and counts to establish the transition period. Since it is a 16-bit counter, it will soon run out, so the overflows are counted, and all converted to a 'unsigned long' with not pretty coding, but that can be an "opportunity for later improvement" : ). It gets further uglier to deal with the 1% error: it was all integer arithmetic so far, but now it has some floats to multiply by a calibration value which will have to be user-determined. It could be easily determined with an LED connected to a transformer (i.e. since that will guarantee a 50Hz source), pointed at the sensor.

    Also, there's no print library to save on space, so the integer printing routine is also bodged modified to incorporate a decimal place (i.e. scale the value to be printed by 100, and then deliberately always put a dot before the two rightmost digits).

    After all that, the result seems accurate : ) and granular.

    So, for instance, with your 580 RPM scenario, if I deliberately apply a 9.6667Hz signal (from a sig-gen, connected to an LED), then it now displays 9.66Hz on the screen, and also displays a RPM value hovering approx. between 579.95 and 580.04, so it's now to within +-0.1RPM typically, at that speed.

     

     

    I still need to tidy the code a bit, but it should be ready in a few days and then I'll put the link on the Cyclops page for downloading.

  • in reply to shabaz

    That’s brilliant, thanks.  I’d looked quickly at the time to see if there was a quick fix, but then put it to one side as I got on with my project.  I think it will be really useful with the improved accuracy, as the Bombe is full of rotating parts, none of which move particularly fast.  Not just that - the mechanical one we’ve used so far does require someone to stick their hand into the machine to hold it against a rotating rod!  I’ll download the update and let you know how it goes.