I’m building a compact cassette drive for data (think ZX Spectrum or C64) using off the shelf parts. The encoding that I’m going to use is tolerant to speed variations, so I can do away without a capstan. I want to use 2 BLDC motors for pulling the tape. The takeup motor will be pulling the tape forward, and the supply motor will be working as an active brake. Their role can be reversed at any time. This is somewhat inspired by D/CAS drives made by TEAC in the 80s.
I’m trying to weigh my options about various control boards. Ideally I would use pre-existing known-good stuff at this stage to minimize variables and keep my effort more focused. For example I would take a Pi Pico, a couple of SimpleFOCMini boards with AS5600 sensors. But SimpleFOCMini, and a lot of other boards that I studied recently as examples, don’t implement current sensing and I’m a little worried if it may be a problem.
Questions:
can braking be implemented without current sensing? I’m not sure if this kind of action has a name, kind of like simulating a brake pad. Or one could say that the motor should try spinning backwards, but not exceeding some set torque.
is it true that cogging can be reduced by applying current sensing?
how SimpleFOCMini can be modified to implement current sensing?
I think you’re too worried about the current sensing. I don’t think you’ll need it at all for this project.
Moving a tape is not difficult, you will able to use (for example) some flat pancake style motors in 2204 size. These are available super-cheap on AliExpress, are pretty flat, and some of the models are pretty decent (others are pretty crappy, have to order some different ones and try). These motors have 7 pole-pairs and fairly high resistance.
To drive a tape, even the SimpleFOC mini will be overpowered. You could use a small integrated driver like the STSPIN233 or the TMC6300…
If you’re interested, I have a small dual BLDC board based on STSPIN233 and an STM32F4 MCU which I’m just testing. It looks quite promising so I could send you one to test.
You won’t really need current sensing, because if you use motors like the ones described, and small drivers like the STSPIN, then the current will remain below 1A. The voltage control will work well enough.
Braking can be implemented just by running the “trailing” motor a little more slowly than the “leading” one, but with limited torque on the leading one so it doesn’t damage the tape.
Various advanced optimisations depend on knowing the current, so the answer is yes, but none of this is implemented in SimpleFOC at the moment. So it’s only a theoretical yes.
Please take a look at Valentine’s designs, like the “Quadrans” or the “Mosquito” - you can find them in this forum.
I’ll be interested to hear what control scheme you settle on
If you use velocity mode, for example, the control would be in terms of angular velocity, which will result in a changing linear velocity (of the tape) since the spindle changes size quite a bit as the tape is reeled onto it. Compared to the empty spindle, the almost full spindle has a much larger diameter.
Thanks for the answers! I’m actually looking at JDPower MY-2813C (2204) as they are the smallest, and I already have some CAD files accounting for their dimensions.
Re: tape speed long-term variation, I actually want to try and use a mouse sensor to track the tape motion. It may not work, in which case oh well… I’m glad this is not for music. I’m more worried about minute speed variations that may be caused by cogging, and they might create very fast phase jitter that would be difficult to track and compensate for.
I’ll be checking out STSPIN233, TMC6300 and the projects that you mentioned. There’s a lot of information here to process. If a controller is an overkill it’s not a problem, underkill is much more difficult to compensate for.
I don’t provide any links because the shops pop up with them, then shut down or run out of stock, but they all use the same photos, so you should see these if you look around.
I’ve posted a number of times about low cogging motors. There are some very cheap ones with cogging that is very low on ali express that I posted about. only a few dollars each with shipping. I have a whole bunch, if you can’t get them hit me up.
If you are going to buy a jdpower one the best one I found was the 3505, it has a ceramic ring magnet and that makes a big difference. However I only bought those instead of aliexpress ones because I needed a reliable repeatable supply and replaceable bearings. If I were you I would go with aliexpress.
You give it a pwm, and that’s it’s torque signal. I combined it with a 3d printed spring to smooth out the cogging and it works pretty well.
If you go that route ask me for the pinouts etc. I also like the raspberry pi picos for this purpose, but a nucleo board is probably better for simplefoc. I used the b-g431b-esc board with considerable success. It includes the power stage.
Interesting, STSPIN233 is limited by 10V. I guess for my purposes that’s fine, in theory I should get away even with 5V, provided that there are enough A.
Ceramic ring magnet sounds really good. 3505, if I’m looking at the right sample, is really huge. I’m not ruling it out, but I would like to try some smaller options first.
DVD drive motors are designed to spin at fast speeds. I looked it up, it seems to be about 600 rpm minimum. Tape at regular travel speed is more like 60rpm. I experimented with DVD motors a long time ago, that was when I first learned about SVPWM. I had only some crude open loop control, but I had some difficulties making it rotate smoothly at slow speeds. A gimbal motor subjectively seemed much smoother. Grain of salt, this was 10 years ago.
It’s a good point about AS5600 update speed, but I’m not sure if it will really be the limiting factor. Do you know how to find out if it’s a problem or not? Is there a known rule how many samples/revolution are required? For example, with i2c at 1MHz and about 80 clock cycles per position read, the loop will be limited to 12500 Hz. At projected 60rpm or 1 rps that’s 3x oversampling the sensor resolution (4096 x 3 = 12288).
I want to use MT6071 in SSI mode in the next board that I’m going to be designing for the next iteration. For now I’m leaning towards AS5600 simply because I’m seeing more offerings of AS5600 breakout boards conveniently packaged with the right kind of magnets. I’ll probably be ordering a few of each anyway and testing them.
I have just realized that the ideal motor that I’m looking for is 3.5" floppy motor. They are a bit too large, so the mechanical construction would become more interesting, with several layers of motors slightly offset. I don’t see them sold separately anywhere though, and I wouldn’t want to murder any floppy drives for that.
You could also get some larger/ faster motors and put them off to the side, then couple them with belts and/or reducers to where the motion actually needs to be applied.
There’s also some designs for axial motors (floppy motors sometimes are), even ones based just on PCB coils…
For the I2C sensors, if you can get 12000Hz off them then please share here how
The best I’ve seen is between 1-2kHz. The I2C protocol is slow, and even if the sensor can do 1MHz, many MCUs only do 400Hz.
I’m just making a back of the napkin estimate. I never tried any high speed i2c stuff. Do you know why it’s so slow? 400kHz (I’m assuming 400Hz is a typo) / 80 clocks per reading = 5000 Hz. That’s better than 2000 Hz. I think rp2040 should be able to handle 1MHz i2c. But I agree that these numbers are not particularly impressive.
I was getting a 1 khz update rate with an as5600 over i2c using the b-g431b-esc1 board. The problem it the waiting. The sensor as to sample the hardware internally and that takes time. I don’t think this sensor could update anywhere near 12 khz even over spi. If you need that you need an actual encoder. Plus if you need that kind of spacial resolution you can’t get it from a magnetic sensor, they need to be calibrated to overcome various sources of error and stuff and there is always some left.
The major advantage of PWM is that the controller does not have to sit there updating. It just gets the information super fast when a pulse comes in. The major downside is the dead spot at the top, also you have to configure the sensor which requires the i2c connection anyway. analog would probably be the fastest, analog also has a glitch at top dead sensor but I was able to use it ok with a pico W but that’ wasn’t using simplefoc.
No, no, we’re confusing things here. This sensors internal sample rate is 150us, so 6.666kHz. It won’t win any speed records with that, but it’s not the limiting factor.
It’s the I2C communication which is slow. This is because SimpleFOC only interacts with I2C in a synchronous way from the controller side. So we have to wait for the I2C result before moving on to doing the next thing in the code. And I2C itself normally runs at 400kHz (yes, kHz, not Hz, sorry!) and is a complex protocol. To perform the read of 2 bytes, the controller first has to write two bytes (address and register), with I2C sending and waiting on ACKs each time, and then read two bytes, again with the extra signalling. This back and forth takes time, certain delays have to be respected each time you switch between reading and writing, before sending the next bytes, etc… so it takes a lot more time than you calculate just multiplying the payload bits by the clock speed.
PWM is not a good option, IMHO. The fastest PWM supported is 920Hz. That means you’re getting less than 1kHz update frequency, with low resolution and high error.
Analog can be a good option, but will be tricky to set up. While you can read it faster, it won’t do you any good to go faster than the sensor’s 6666Hz sample rate.
All in all I’d stay away from this sensor and prefer a model using SPI or ABZ type interfaces.
You’ll also get lower error (no extra error introduced by the PWM measurements) and the ability to control/configure the sensor and check its status. Also it’s a bus system, so multiple devices can share the same I2C bus.
This sensor is quite hard to use, in my experience, due to its many modes. In the end you need I2C to configure it. But yes, its SSI interface is much faster, as also its ABZ interface. Its PWM is 994.4Hz in the fast mode, so only marginally faster than the AS5600 and certainly not worth switching to for that reason.
It doesn’t give its sample rate in the datasheet, but it states it can handle up to 55kRPM and has an output propagation delay of 5us, which would imply it is considerably faster than the AS5600.
Note that the AS5600 is marketed as a digital potentiometer, IIRC, rather than as a position sensor for motor control.
I have used the MT6701 in both I2C and SSI (SPI-like) modes. For low speed (0-50 rad/s) use cases, I did not actually notice any difference in performance - I’m not sure how fast you would have to go before it becomes an issue.
Note that you can only write/configure I2C if you have 5V Vcc on the MT6701 but it supports 3.3V - this makes the I2C mode kind of awkward (i.e. with the wrong supply voltage for the chip, the I2C is read-only mode, and some of the presets are very bad - like ABZ default resolution is something like 4ppr) . If you only need to read angle at full precision (14 bits?) at high speed you should use the SSI mode, otherwise I would use I2C @ 5V.
Note: the driver library does not have anything working for I2C on MT6701 - I had to modify the file to get it to work. I guess I should clean it up and open a PR but I2C is definitely not as “drag and drop” as SSI at this time.
Yup, I hit the 5V / 3.3V thing and decided to pick it up another day
In the end I figured the way this works, it will cause a lot of problems for users and therefore a lot of questions and support effort.
So I dropped it after implementing SSI in favor of other, easier to use sensors and other topics…
If you feel like it, we’d certainly be happy about it!
