Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate the use of the DRV5053 sensor #17

Open
darraghbr opened this issue Mar 7, 2021 · 12 comments
Open

Investigate the use of the DRV5053 sensor #17

darraghbr opened this issue Mar 7, 2021 · 12 comments

Comments

@darraghbr
Copy link
Contributor

In place of the SS495A sensor we could instead use a comparable TI part, namely the DRV5053. Pros of the DRV5053 are it is significantly less expensive (less than half the cost) for a similar spec part, they are pin compatible.

I have prototyped the circuit on a breadboard and tested side by side the SS495A sensor and the DRV5053, below is the waveform generated by the two sensors, the DRV is on the left and the SS495A is on the right, as you can see the output is much higher from the SS495.

The polarity is reversed between the sensors, but in theory you just have to install the magnet in the other way around.

I checked it using a magnet on which I marked a side and offered it up to the 2 sensors.

image

Do people think the lower response and reversal of polarity will be an issue?

Below is the breadboard set up for reference.

PXL_20210306_123721829 (Large)

@drspangle
Copy link
Owner

The inverted polarity shouldn't be an issue, but I'm wondering about the response time. Do you have a rough idea of what the expected (reliable) sampling rate would be given the small measurement tolerance?

@darraghbr
Copy link
Contributor Author

The SS495A datasheets state a response time of 3 μs and the DRV state a typical of 13 μs and a max of 25 μs. I believe either one is appropriate. In terms of sampling rate I'm not sure, but the DRV sensor has a much more detailed application note around designing RC filters to achieve an appropriate bandwidth.

Ultimately it comes down to the filament, it would be interesting to see what sort of frequencies the variations in filament occur at. Can you detect mains switching frequency in the diameter of filament? Of course it wouldn't be at the same frequency unless your feedrate is the same as the original extruder.... Something to keep me awake at night...

@blurfl
Copy link
Contributor

blurfl commented Mar 8, 2021

The reduced response of the DRV5053 is certainly an issue. We're measuring very small differences in movements of the magnet and the chart makes it look like the SS495A has more than four times the full range.

@darraghbr
Copy link
Contributor Author

The sensors are closer to one another than you might think, in terms of linear range the DRV sensor beats the SS495 (only by 6 mT but there we are)

Because we are going through a calibration routine I suspect it won't matter, and because we are in a fairly loosely coupled system (lets face it the extruder of a printer can't respond at the rates we are talking about here) I suspect it's all in the weeds.

  SS495A DRV5053OA
Limits (mT) 67 73
Linearity (%) 1 1
Sensitivity (mV/mT) 31.25 11
Output delay time (μs) 3 13

@blurfl
Copy link
Contributor

blurfl commented Mar 8, 2021

The sensitivity value of the SS495A is more than three times that of the DRV5030A. That’s a lot. We won’t be affected by the limit, we’re working with a small magnet. Our interest is how much the signal changes for a small change in mT.

@drspangle
Copy link
Owner

I must admit that as a software guy, the physics and electrical engineering behind the final determination of whether this change will be a problem is increasingly beyond my expertise. However, I would like to offer two things.

First, maybe it would be worth reaching out to Tom to see if he had considered using this alternative sensor, perhaps he has some knowledge or did some tests on this.

Second, it might be worth considering this change in terms of the maximum sensitivity per time unit, rather than overall sensitivity or maximum frequency of a reliable sample in ideal conditions. If we take this approach, it would be more practical to be able to calculate the maximum detectable deviation for a given feedrate, and we can also determine whether this detectable deviation is within an acceptable spec over a number of observations. This is very much related to what I had in mind for #5.

@darraghbr
Copy link
Contributor Author

You say we are working with a small magnet, they are quite potent and are quite close to the sensor. Do you know for a fact that we are within the linear region for the sensor?

@darraghbr
Copy link
Contributor Author

There are also other SKUs of the DRV5053, including ones with significantly higher sensitivity, in the realm of 90 mV/mT, but they become saturated at much lower levels.

@darraghbr
Copy link
Contributor Author

It would be interesting to see what the raw values shake out to be during the calibration process.

@blurfl
Copy link
Contributor

blurfl commented Mar 8, 2021

Maximum sensitivity per time unit would be a function of sensitivity and output delay time. In a device that
The difference in cost here is very small - these are not expensive parts. The cost of shipping for either one will be much more than the cost of the part. The sensor in a sensing circuit isn't the best place to cost engineer.

A bigger cost saving might be to use a RPi pico ($4) instead of the custom PCB. Faster, on-board data storage, serial IO as well as I2C, available without custom manufacture.

@drspangle
Copy link
Owner

A bigger cost saving might be to use a RPi pico ($4) instead of the custom PCB. Faster, on-board data storage, serial IO as well as I2C, available without custom manufacture.

While this is true, this is both a substantial change to the hardware design and also a total redo of the firmware (including a shift to a different development environment and language). I'm not sure whether this is a good idea or not at this stage. There is also the potential for a shortfall in available volume of parts.

All of this is a useful discussion, so let's keep hashing this out until we arrive at a practical answer. The goal is to keep the cost as low as possible, but there is an obvious multi-objective trade-off between cost, manufacturability/availability, and utility. It is totally unclear to me what the impact is on these objectives with each of these proposed changes right now.

@blurfl
Copy link
Contributor

blurfl commented Mar 8, 2021

a substantial change to the hardware design and also a total redo of the firmware

That's a fact. Probably better as a fork. It does work a treat, though 😁.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants