I have a RC car with motor 25 kv , I wanted to minimize the motor speed from 55 miles /s to 1 m/s speed and to add encoder to it to make auonomouse a specific purpose in robotics application
if someone have idea about the components required and the steps required
Related
I am currently in the development of small PMSM motor controllers. Usually based on some ARM M4F (yes F, as new forms of vector control benefit from FPU) at > 100 MHz and flash in the area of 128k to 1M. The technology node is usually in the 90-120 nm area, but now we see more in the 40 nm area. Clearly that is not top notch so it is really crossing my mind, wheather external flash as program storage might be a way out when it is combined to large internal SRAM as i.e. ESP32 or ARM TCM.
I am currently evaluating this on an ESP32-C3 employing 4 Mbyte external serial flash and I am really excited in terms of price/performance.
I ran a speed comparision on my application - typical FOC algorithm. The execution time is 20,8 µs at 160 MHz CPU clock, on the nearest ESP32-S2 at 240 MHz and internal flash it is 16,7 µs. Did I oversee something?
When I record a signal with USRP N320 SDR, it has some problems on the edges of the spectrum. For example, when I choose sample rate 50 Msps, 2 MHz of the start of the spectrum and 2 MHz of the end of the spectrum, gives the wrong results. When it see a pulse on the edges it decreases the power and changes the frequency little bit. But 46 MHz bandwidth is perfectly working.
Sample rate: 50 Msps, Properly working bandwidth: 46 MHz
Sample rate: 100 Msps, Properly working bandwidth: 90 MHz
Sample rate: 200 Msps, Properly working bandwidth: 180 MHz
I tried to filter the edges with bandpass filter but it does give the OOOOOO problem. Even if I choose the sample rate 50 Msps. But normally, I can record successfully without bandpass filter when I choose sample rate 200 Msps.
Is there a solution to record the edges correctly. Or filtering it without dropping samples.
First off:
I tried to filter the edges with bandpass filter but it does give the OOOOOO problem
means that your computer isn't fast enough to apply the filter to the data stream. That might mean two things: you've designed a filter that's too long and could be shorter and still do what you want, or what you want to do requires a filter of that length and you will need to find a faster PC (hard) or use a faster filter implementation (did you try the FFT filters?).
For example, when I choose sample rate 50 Msps, 2 MHz of the start of the spectrum and 2 MHz of the end of the spectrum, gives the wrong results.
This is not surprising! Remember that anything with a ADC needs an anti-aliasing filter on the analog side, and these can't be arbitrarily sharp. So, necessarily, the spectrum at the edge of your band gets a bit dampened, and there's a bit of aliasing there. The dampening, you could counteract by throwing an equalizing filter on your PC at it, which would need to necessarily be more compute-intense than what is happening on the USRP, but the aliasing of the lowest frequencies onto the highest, and vice versa, due to finite steepness of the analog anti-aliasing filter you cannot repair. That's the signal processing blues for any kind of acquisition device.
There's one trick though, which the USRP uses: when your requested sampling rate is lower than the ADC's sampling rate, the USRP can internally apply a (better!) digital filter to select that target sampling rate as bandwidth, and decimate to that.
Thus, depending on the ADC rate to output sampling rate relationship (in UHD, the ADC rate is called "master clock rate", MCR), there's further digital filtering and decimation going on in the digital logic inside the N320. These filters also can't be infinitely sharp – and you might see that.
Generally, you'd want that decimation between MCR and the sampling rate you've requested to be an even number, and not too large. Don't have the N320's digital signal processing architecture in my head right now, but I bet using a decimation that's a multiple of 4 or even 8 is a good move – you get to use the nicer half-band filters then.
Modern UHD also has the filter API, with which you can work with these digital filters manually; this rarely is what you really want to do here, though.
I have a raspberry and an auxiliary PCB with transistors for driving some LED strips.
The strips datasheets says 12V, 13.3W/m, i'll use 3 strips in parallel, 1.8m each, so 13.3*1.8*3 = 71,82W, with 12 V, almost 6A.
I'm using an 8A transistor, E13007-2.
In the project i have 5 channels of different LEDs: RGB and 2 types of white.
R, G, B, W1 and W2 are directly connected in py pins.
LED strips are connected with 12V and in CN3, CN4 for GND (by the transistor).
Transistor schematic.
I know that that's a lot of current passing through the transistors, but, is there a way to reduce the heating? I think it's getting 70-100°C. I already had a problem with one raspberry, and i think it's getting dangerous for the application. I have some large traces in the PCB, that's not the problem.
Some thoughts:
1 - Resistor driving the base of the transistor. Maybe it won't reduce heating, but i think it's advisable for short circuit protection, how can i calculate this?
2 - The PWM has a frequency of 100Hz, is there any difference if i reduce this frequency?
The BJT transistor you're using has current gain hFE of roughly 20. This means that the collector current is roughly 20 times the base current, or the base current needs to be 1/20 of the collector current, i.e. 6A/20=300mA.
Rasperry PI for sure can't supply 300mA current from the IO pins, so you're operating the transistor in linear region, which causes it to dissipate a lot of heat.
Change your transistors to MOSFETs with low enough threshold voltage (like 2.0V to have enough conduction at 3.3V IO voltage) to keep it simple.
Using a N-Channel MOSFET will run much cooler if you get enough gate voltage to force to completely enhance. Since this is not a high volume item why not simply use a MOSFET gate driver chip. Then you can use a low RDS on device. Another device is the siemons BTS660 (S50085B BTS50085B TO-220). it is a high side driver that you will need to drive with an open collector or drain device. It will switch 5A at room temperature with no heat sink.It is rated for much more current and is available in a To220 type package. It is obsolete but available as is the replacement. MOSFETs are voltage controlled while transistors are current controlled.
My project uses a simple L9110S driver module and it controls 2 motors of the type JGA25-370 (DC 12V, 100RPM). So far I managed to easily control it by setting the pins of the L9110S H-bridge to either high or low.
However, I would like to add PWM control via the Raspberry Pi for this type of motor. Would anyone have any suggestions what would be the best frequency to set for PWM, so that I can safely change the motor speed with the duty cycle, without having the motors jerk and twitch? I have been experimenting and with values higher than 250 Hz, the motors are behaving bad. What would be the "safest" setting?
The motors are currently powered by 8x 1.2V NiMH batteries, so they get around 10 V.
My spartan 3a fpga board has a 50mhz clock while implementing a microblaze with ram ddr2 , it required a frequency of 62mhz which was edited by my program , when asked about this , they told me that 60mhz clock is used to generate other clocks internally but how does a 50mhz clock produce a 62mhz clock which is higher !?
in Xilinx Spartan devices you can use so called DCMs (digital clock managers) that give you a whole lot of possibilities; see Spartan User Guide or Xilinx Spartan 3 DCM. with the synthesizer option, clock multiplication/division is possible.
There are built in technologies that multiply the clock to higher frequencies. See Frequency Multiplier and Phase Locked Loop
under your design name in Implementation window in ISE right click and add new sorce select IPcore then select clocking wizard you can enter the primary freq : 50 mhz and required out freq: 62 mhz and the core generator will do it for you.