TSDZ2 48v 2020 new firmware

beemac · May 19, 2021

casainho said:
beemac said:

Have been thinking about how to manage the two codebases to keep features common with a minimum of legwork;

Idea was to refactor the existing motor controller code slightly - move anything hardware specific out of ebikeapp.c and into a hardware abstraction class that reads things like torque sensor or pas - then make ebikeapp.c part of common firmware... in other words separating all the hardware specific motor control code from the higher level functionality.

I was thinking the interface for motor.c should be simplified to just motor control parameters - such as:

target pwm (with corresponding ramp up/down in units/sec) OR target current (with corresponding ramp up/down in units/sec)
limits for pwm/current/rpm/power - rpm is new, and power may be unnecessary in addition to current.

So that would mean to move any code that adjusts motor current or pwm parameters based on torque or pas values out of motor.c...

Click to expand...

I see the following disadvantages:

1. 8 bits VS 32 bits microcontroller, meaning the old code is optimized (I mean all the code, not only the motor code) for 8 bits and that would be a limitation (in quality output) for the new motor controller.

2. The compiler SDCC for the old one is more limited and the code is a mess because of that, with all variables global.

1. Sure - but there's not much in the rest of the code right now that would benefit greatly from 32bit from what I can see.

2. True - but to refactor all the code wouldn't provide that many benefits right now and would probably be more work - and would lock out all the existing users from new functionality (or we need to maintain two motor codebases).

I think we should use as much of the old code as possible for now to get things working - using new 32bit code where it really makes a difference - e.g. the motor control code. Then if and when we want to improve other parts of the code we can replace those with new 32bit code.

Of course it's quite possible that once i start porting stuff across I might fed up with ifdefs all over the place

casainho · May 19, 2021

beemac said:
casainho said:

beemac said:

Have been thinking about how to manage the two codebases to keep features common with a minimum of legwork;

Idea was to refactor the existing motor controller code slightly - move anything hardware specific out of ebikeapp.c and into a hardware abstraction class that reads things like torque sensor or pas - then make ebikeapp.c part of common firmware... in other words separating all the hardware specific motor control code from the higher level functionality.

I was thinking the interface for motor.c should be simplified to just motor control parameters - such as:

target pwm (with corresponding ramp up/down in units/sec) OR target current (with corresponding ramp up/down in units/sec)
limits for pwm/current/rpm/power - rpm is new, and power may be unnecessary in addition to current.

So that would mean to move any code that adjusts motor current or pwm parameters based on torque or pas values out of motor.c...

Click to expand...

I see the following disadvantages:

1. 8 bits VS 32 bits microcontroller, meaning the old code is optimized (I mean all the code, not only the motor code) for 8 bits and that would be a limitation (in quality output) for the new motor controller.

2. The compiler SDCC for the old one is more limited and the code is a mess because of that, with all variables global.

Click to expand...

1. Sure - but there's not much in the rest of the code right now that would benefit greatly from 32bit from what I can see.

2. True - but to refactor all the code wouldn't provide that many benefits right now and would probably be more work - and would lock out all the existing users from new functionality (or we need to maintain two motor codebases).

I think we should use as much of the old code as possible for now to get things working - using new 32bit code where it really makes a difference - e.g. the motor control code. Then if and when we want to improve other parts of the code we can replace those with new 32bit code.

Of course it's quite possible that once i start porting stuff across I might fed up with ifdefs all over the place

Ok, just we can be aware of this.

And the ifdefs will make the code more difficult to read and maintain.

But there is one important thing, that is you are considering to keep developing and maintaining for both V1 and V2 controllers and that means much more work, as you need to have 2 EBikes at least, one with V1 and V2 controller, to be able to test, otherwise it will a problem if you are developing and not testing, providing problems to the users and get busy to solve the issues without being able to test... -- are you ready to do that? Because I am not, I do not have space to keep EBikes only for the work of developing the firmware and I do not have time and motivation to being working for others for free (I mean that I like to share what I develop for my own use, but not supporting others with things I am not using at the moment). I am abandoning the 860C and SW102 displays because simple I do not use them.

beemac · May 19, 2021

casainho said:
beemac said:

casainho said:

beemac said:

Have been thinking about how to manage the two codebases to keep features common with a minimum of legwork;

Idea was to refactor the existing motor controller code slightly - move anything hardware specific out of ebikeapp.c and into a hardware abstraction class that reads things like torque sensor or pas - then make ebikeapp.c part of common firmware... in other words separating all the hardware specific motor control code from the higher level functionality.

I was thinking the interface for motor.c should be simplified to just motor control parameters - such as:

target pwm (with corresponding ramp up/down in units/sec) OR target current (with corresponding ramp up/down in units/sec)
limits for pwm/current/rpm/power - rpm is new, and power may be unnecessary in addition to current.

So that would mean to move any code that adjusts motor current or pwm parameters based on torque or pas values out of motor.c...

Click to expand...

I see the following disadvantages:

1. 8 bits VS 32 bits microcontroller, meaning the old code is optimized (I mean all the code, not only the motor code) for 8 bits and that would be a limitation (in quality output) for the new motor controller.

2. The compiler SDCC for the old one is more limited and the code is a mess because of that, with all variables global.

Click to expand...

1. Sure - but there's not much in the rest of the code right now that would benefit greatly from 32bit from what I can see.

2. True - but to refactor all the code wouldn't provide that many benefits right now and would probably be more work - and would lock out all the existing users from new functionality (or we need to maintain two motor codebases).

I think we should use as much of the old code as possible for now to get things working - using new 32bit code where it really makes a difference - e.g. the motor control code. Then if and when we want to improve other parts of the code we can replace those with new 32bit code.

Of course it's quite possible that once i start porting stuff across I might fed up with ifdefs all over the place

Click to expand...

Ok, just we can be aware of this.

And the ifdefs will make the code more difficult to read and maintain.

But there is one important thing, that is you are considering to keep developing and maintaining for both V1 and V2 controllers and that means much more work, as you need to have 2 EBikes at least, one with V1 and V2 controller, to be able to test, otherwise it will a problem if you are developing and not testing, providing problems to the users and get busy to solve the issues without being able to test... -- are you ready to do that? Because I am not, I do not have space to keep EBikes only for the work of developing the firmware and I do not have time and motivation to being working for others for free (I mean that I like to share what I develop for my own use, but not supporting others with things I am not using at the moment). I am abandoning the 860C and SW102 displays because simple I do not use them.

are you planning to convert all four of your ebikes to v2 boards? I have two ebikes and for now was going to have one v1 and one v2 - but that's just because I only have two v2 boards - one for dev and one to put in a bike...

Anyway - I'm sure once I start work that it will become apparent if the idea will work or not...

casainho · May 19, 2021

beemac said:
casainho said:

beemac said:

casainho said:

I see the following disadvantages:

1. 8 bits VS 32 bits microcontroller, meaning the old code is optimized (I mean all the code, not only the motor code) for 8 bits and that would be a limitation (in quality output) for the new motor controller.

2. The compiler SDCC for the old one is more limited and the code is a mess because of that, with all variables global.

Click to expand...

1. Sure - but there's not much in the rest of the code right now that would benefit greatly from 32bit from what I can see.

2. True - but to refactor all the code wouldn't provide that many benefits right now and would probably be more work - and would lock out all the existing users from new functionality (or we need to maintain two motor codebases).

I think we should use as much of the old code as possible for now to get things working - using new 32bit code where it really makes a difference - e.g. the motor control code. Then if and when we want to improve other parts of the code we can replace those with new 32bit code.

Of course it's quite possible that once i start porting stuff across I might fed up with ifdefs all over the place

Click to expand...

Ok, just we can be aware of this.

And the ifdefs will make the code more difficult to read and maintain.

But there is one important thing, that is you are considering to keep developing and maintaining for both V1 and V2 controllers and that means much more work, as you need to have 2 EBikes at least, one with V1 and V2 controller, to be able to test, otherwise it will a problem if you are developing and not testing, providing problems to the users and get busy to solve the issues without being able to test... -- are you ready to do that? Because I am not, I do not have space to keep EBikes only for the work of developing the firmware and I do not have time and motivation to being working for others for free (I mean that I like to share what I develop for my own use, but not supporting others with things I am not using at the moment). I am abandoning the 860C and SW102 displays because simple I do not use them.

Click to expand...

are you planning to convert all four of your ebikes to v2 boards? I have two ebikes and for now was going to have one v1 and one v2 - but that's just because I only have two v2 boards - one for dev and one to put in a bike...

Anyway - I'm sure once I start work that it will become apparent if the idea will work or not...

First I must say that I decided to work on the motor controller V2 firmware because I have the expectation that it reduces the TSDZ2 motor noise, which is a top priority for me. First top priority were motor energy efficiency and I got it with our firmware. Now with motor controller V2, I hope to get less motor noise and increase a bit the efficiency. I want my EBikes to be low on weight, so I want small batteries and then I need energy efficiency - and I wish we could build a DIY small motor version (same concept as for build wireless remote) as would be important for the road bike.

About my 4 ebikes, I may dismantle some of them because of dynamics of my family and covid (there are no events of MTB but I know people riding in group of road cycling and there are events of trail run which I also do), I bought a mini cargo bike that I should get it maybe in 1 month and I am thinking in buying a road bike.

So the plan for my EBikes are:
- use only the motor controller V2 with our developed OpenSource firmware
- no display at all, just the TSDZ2 EBike wireless controller with the wireless remote (on days riding for sport, I will use my Garmin Edge 830 to have all the fitness metrics and map navigation)

This means I will not be able to test anymore the firmware for the displays or the firmware for the TSDZ2 motor controller V2.

To keep developing and maintain the firmware for the hardware I do not use, I would need to have extra EBikes using that hardware and I would need to use that EBikes!! because the only way to develop is to "eat our own dog food". I do not have the space at my house nor the life time to do that, as I doing this as my hobby and I do not want to get professional on this.

And my mini cargo bike should be of same width (1.8 meters as a regular bicycle), 18 and 16 inches wheels, similar design:

casainho · May 19, 2021

stancecoke said:
casainho said:

A big issue is that I can not change / see anymore the configurations of the project, like I can't see the PWM configurations for instance

Click to expand...

Do you mean the App perspective or the related source code?

for the App perspective go to Window-->Perspective-->Open Perspective-->Other-->DAVE CE

This is the issue I have when I open the project:

Can you please give a look on your side? maybe you know how to fix it...

michih. · May 19, 2021

the motor is significantly quieter with the new controller! I can already say that. I tested the controller with the tft500 in one of my old motors. the unpleasant higher frequencies are gone. A lower consumption and therefore less heat generation and the performance of the mspider65 version would be perfect.

MFG Michael

casainho · May 19, 2021

michih. said:
the motor is significantly quieter with the new controller! I can already say that. I tested the controller with the tft500 in one of my old motors. the unpleasant higher frequencies are gone. A lower consumption and therefore less heat generation and the performance of the mspider65 version would be perfect.

Why do you say lower consumption? Isn't there already with original firmware? As also lower temperature?

What you mean by performance of the mspider65 version? What do you feel different?

michih. · May 19, 2021

casainho said:
michih. said:

the motor is significantly quieter with the new controller! I can already say that. I tested the controller with the tft500 in one of my old motors. the unpleasant higher frequencies are gone. A lower consumption and therefore less heat generation and the performance of the mspider65 version would be perfect.

Click to expand...

Why do you say lower consumption? Isn't there already with original firmware? As also lower temperature?

What you mean by performance of the mspider65 version? What do you feel different?

This meant less consumption than with the V1.
the mspider65 version is super responsive. the motor does not revolve and reacts fairly well to changes in force.
drives better than the current bosch gen4.
the paired with the v2 controller (less consumption and quieter) is a very high level !!

mfg michael

stancecoke · May 19, 2021

casainho said:
This is the issue I have when I open the project:

Hm, it works for me without problems.
- Download the repo as zip-file from github
- unpack it to your harddrive
- open a new empty workspace in DAVE
- choose File-->Open Projects from File System
- choose the DAVE_FOC_PROJECT folder in the dialog

The project opens in the DAVE CE perspective.

regards
stancecoke

casainho · May 19, 2021

michih. said:
casainho said:

michih. said:

the motor is significantly quieter with the new controller! I can already say that. I tested the controller with the tft500 in one of my old motors. the unpleasant higher frequencies are gone. A lower consumption and therefore less heat generation and the performance of the mspider65 version would be perfect.

Click to expand...

Why do you say lower consumption? Isn't there already with original firmware? As also lower temperature?

What you mean by performance of the mspider65 version? What do you feel different?

Click to expand...

This meant less consumption than with the V1.
the mspider65 version is super responsive. the motor does not revolve and reacts fairly well to changes in force.
drives better than the current bosch gen4.
the paired with the v2 controller (less consumption and quieter) is a very high level !!

So I understand that hardware V2 original firmware already provides better comsuption and less noise, and the only thing missing and that you expect is a super responsive motor.

I think the super responsive can be improved by:
- tweaking the motor currents, to make it accelerating faster but sure more current and heat will be generated
- keep using our torque sensor calibration that original firmware does not provide
- increase the EBike loop speed to the same as mspider65 is using

This new microcontroller is only twice as fast, that is not much. But it is 32 bits instead of 8 bits. BUT the motor control FOC should use much more resources than comparing to V1, so, at least I hope we can keep the same EBike loop speed as mspider65 is using.

michih. · May 20, 2021

casainho said:
michih. said:

casainho said:

michih. said:

the motor is significantly quieter with the new controller! I can already say that. I tested the controller with the tft500 in one of my old motors. the unpleasant higher frequencies are gone. A lower consumption and therefore less heat generation and the performance of the mspider65 version would be perfect.

Click to expand...

Why do you say lower consumption? Isn't there already with original firmware? As also lower temperature?

What you mean by performance of the mspider65 version? What do you feel different?

Click to expand...

This meant less consumption than with the V1.
the mspider65 version is super responsive. the motor does not revolve and reacts fairly well to changes in force.
drives better than the current bosch gen4.
the paired with the v2 controller (less consumption and quieter) is a very high level !!

Click to expand...

So I understand that hardware V2 original firmware already provides better comsuption and less noise, and the only thing missing and that you expect is a super responsive motor.

I think the super responsive can be improved by:
- tweaking the motor currents, to make it accelerating faster but sure more current and heat will be generated
- keep using our torque sensor calibration that original firmware does not provide
- increase the EBike loop speed to the same as mspider65 is using

This new microcontroller is only twice as fast, that is not much. But it is 32 bits instead of 8 bits. BUT the motor control FOC should use much more resources than comparing to V1, so, at least I hope we can keep the same EBike loop speed as mspider65 is using.

yes right, the v2 original is quieter!
a drivability like the mspider version paired with the advantages of the v2 would be great!
would always be better. but i think it is limited by the internal torque sensor. i have a rocky mountain powerplay. that's a different system. in my eyes, the bike is the reference at the moment. I haven't driven anything like it yet! the range of the torque sensor is much wider. the motor reacts immediately and accelerates quickly because it would pulverize the blue gear of the tsdz2.
I don't think you can get much more than V2 / mspider out of this engine. maybe a finer and broader tuning of the torque sensor is possible due to the higher performance of the controller, but I don't know enough about that.

mfg michael

casainho · May 20, 2021

michih. said:
I don't think you can get much more than V2 / mspider out of this engine. maybe a finer and broader tuning of the torque sensor is possible due to the higher performance of the controller, but I don't know enough about that.

I don´t think much more can be done on the torque sensor side. We already have documented how to improve from the hardware side and from the firmware side.

casainho · May 20, 2021

stancecoke said:
casainho said:

This is the issue I have when I open the project:

Click to expand...

Hm, it works for me without problems.
- Download the repo as zip-file from github
- unpack it to your harddrive
- open a new empty workspace in DAVE
- choose File-->Open Projects from File System
- choose the DAVE_FOC_PROJECT folder in the dialog

The project opens in the DAVE CE perspective.

Thanks, I got it. Seems I was not opening the project properly.

So, I tested the motor using throttle and I validated the throttle reading using the debugger. I also validated the code inside Systick interrupt. The motor shakes seems to kind of rotate, but pulls a lot of current, but since I am using a lab power supply with limited current, I am not burn anything yet

@stancecoke, can you please give a look at the last commit I did? Can you please validate the configurations? maybe doing a diff of files or such. Thank you.

stancecoke · May 20, 2021

casainho said:
can you please give a look at the last commit I did?

I had a short look at the diffs:
https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2/commit/d2083cfd89d013ead2e0b2bdf96e0e2a9fd3aa5a

To be honest, I don't understand what/why you have changed something in the syscalls.c

I can't help more, as I have no hardware...

regards
stancecoke

casainho · May 20, 2021

stancecoke said:
casainho said:

can you please give a look at the last commit I did?

Click to expand...

I had a short look at the diffs:
https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2/commit/d2083cfd89d013ead2e0b2bdf96e0e2a9fd3aa5a

To be honest, I don't understand what/why you have changed something in the syscalls.c

I can't help more, as I have no hardware...

I changed syscalls.c because there was some issue when building with my Makefile.

I wish you guys did notes about the hardware, how is the setup like the PWM pins, ADC for current measurements. The only way for me to get that information is visually with DAVE?

Well, maybe I need more time to look carefully and start from scratch.

stancecoke · May 20, 2021

casainho said:
how is the setup like the PWM pins, ADC for current measurements

Why do you and so many other guys allways use full quotes???? This is not helpful in any way!!! You can click the "Post Reply" button below the latest post, then the thread appears below the editor area and you can quote the single sentence, you are refering to, by marking it and then press the " at the beginning of the referred post!

@abrainer has listed the pin assignment in the .odt file several weeks ago. So all information is present! Perhaps it is more comfortabel to paste that information to a wiki page, so you don't have to download and open the .odt file...

regards
stancecoke

casainho · May 20, 2021

stancecoke said:
casainho said:

how is the setup like the PWM pins, ADC for current measurements

Click to expand...

Why do you and so many other guys allways use full quotes???? This is not helpful in any way!!! You can click the "Post Reply" button below the latest post, then the thread appears below the editor area and you can quote the single sentence, you are refering to, by marking it and then press the " at the beginning of the referred post!

@abrainer has listed the pin assignment in the .odt file several weeks ago. So all information is present! Perhaps it is more comfortabel to paste that information to a wiki page, so you don't have to download and open the .odt file...

My idea is to keep messages short. I did not understand how can I quote the single sentence using the procedure you said.

Thanks for remembering about that file. Still, there are information there missing but that you guys must have, like the pins polarity. On the sheet, for instance it says: Pin 0.2, PWM High Phase V - but is missing the polarity information.

Also you did mention before something about the phase current signal need to be inverted... all this details, I expected to write on like config.h file. On previous firmwares I have like pins.h where I have the definition for every pin and some important notes. I think the wiki can probably get outdated, or at least I focus more on the code files.

One question: the code does not support hall sensors, right? If I understood correctly, the FOC library just support sensorless. I can see sample project code for hall sensors only or FOC sensorless only, and there are even older versions for FOC, with more simple project structure, easy to understand.

I may start to try make the motor running using the hall sensors code, as it should be easier and does not depend of so much parameters. That will let me validate things like the PWM polarity and shunt resistor.

abrainer said:
I had got the engine running. However, only in V/f open loop mode. The control of the output stage transistors is noted in the table with phase x high/low.
The circuit structure of the current measurement corresponds to the Infineon example circuits. I did not measure the gain of the current measurement.
I have drawn the circuit of the output stage (picture attached).

stancecoke · May 20, 2021

casainho said:
I did not understand how can I quote the single sentence using the procedure you said.

Here two screenshots:

casainho said:
the FOC library just support sensorless.

@mxlemming posted a link to the infineon forum, where excactly this was discussed:
https://www.infineonforums.com/threads/5320-How-to-change-Dave4-PMSM-FOC-app-from-sensorless-to-Hall

you can manipulate the values PLL_Estimator.RotorSpeed_In and PLL_Estimator.RotorAngleQ31.
This values are update in the FOC so you need to change them after the FOC call.

so you have to overwrite the angle and speed from the observer with the angle and speed from the hallsensor processing before calling the PWM_SVM_SVMUpdate command.

https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2/blob/d2083cfd89d013ead2e0b2bdf96e0e2a9fd3aa5a/DAVE_FOC_PROJECT/Dave/Generated/PMSM_FOC/pmsm_foc_control.c#L167

regards
stancecoke

regards
stancecoke

beemac · May 23, 2021

I just submitted a PR to tweak a couple of bits in the makefile - to make things work on Windows. I don't have a *nix install to test these changes to make sure it's not breaking anything...

Linker refused to find CLKVAL1_SSW/CLKVAL2_SSW in startup_XMC1300.S - doing a bit of digging seems that the capital S extension should force GCC to run the preprocessor before assembly (which would pick up the #defines of those two variables). For whatever reason on Windows this doesn't seem to happen...

I added a switch to the makefile to force GCC to preprocess all assembler files - hopefully this won't cause problems for others.

I also updated the 2nd reference to objcopy to it's full name - I assume both should be using the same objcopy?

https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2/pull/2

beemac · May 23, 2021

casainho said:
I wish you guys did notes about the hardware, how is the setup like the PWM pins, ADC for current measurements. The only way for me to get that information is visually with DAVE?

Did you see this doc in the wiki that stancecoke uploaded - has all the pins documented: https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2/blob/master/Documentation/XMC1303%20pin%20assignment%20Tongsheng%20Controller.odt

Code:

XMC1303 pin assignment Tongsheng Controller
Pin	Port	Funktion	Cable color/connector
1	2.4	U Battery 1,99V @ 34,6 Vbat	
2	2.5	Analog input J7 left, J7 right = 5V (not used)	
3	2.6	Anlalog input over 2k2 to FB Pin XL7005A (Voltage measurement)	
4	2.7	Ca. 2,2V (unknown origin)	
5	2.8	Current Total ADC	
6	2.9	Current Phase U ADC	
7	2.10	Current Phase V ADC	
8	2.11	Current Phase W ADC	
9	VSS		
10	VDD		
11	1.5	Light switching output	
12	1.4	high	
13	1.3	PWM out Torque sensor, pulse length 2.5µs high, distance 20µs	
14	1.2	Hallsensor 3	Hall cable blue
15	1.1	Hallsensor 2	Hall cable yellow
16	1.0	Hallsensor 1	Hall cable green
17	0.0	PWM High Phase U	Motor cable green
18	0.1	PWM Low Phase U	
19	0.2	PWM High Phase V	Motor cable blue
20	0.3	PWM Low Phase V	
21	0.4	Speed Signal	Sensor cable white
22	0.5	PAS 1 Signal	PAS cable blue
23	0.6	RX Display communication	Display cable orange
24	0.7	TX Display communication	Display cable brown
25	VSSP		
26	VDDP		
27	0.8	PWM High Phase W	Motor cable yellow
28	0.9	PWM Low Phase W	
29	0.10		
30	0.11		
31	0.12		
32	0.13	PAS 2 Signal	PAS cable yellow
33	0.14	SWD Debug Pin	Sensor cable purple
34	0.15	SWCLK Debug Pin	Sensor cable black
35	2.0	Serial signal on unused pad 1	
36	2.1	Input from unused pad 2	
37	2.2	Analog value torque sensor	
38	2.3	Analogsignal 2,5V	
		Lichtausgang +6V	Sensor cable green
		U Mos Driver and torque sensor 12,7V	
		GND	Sensor cable orange
		+5V	Sensor cable brown
		GND	Display cable black
		VBatt	Display cable green
		VBatt Motor Ein Spannung kommt von Display	Display cable white
		Vermutlich Brake Sensor	Display cable purple

Torque sensor supplies negative pulse (approx.5µs) with level that is torque dependent.
Inductance L = 76µH 36V Motor, 135µH 48V Motor.

casainho · May 23, 2021

beemac said:
Did you see this doc in the wiki that stancecoke uploaded - has all the pins documented: https://github.com/OpenSourceEBike/TSDZ2_motor_controller_v2/blob/master/Documentation/XMC1303%20pin%20assignment%20Tongsheng%20Controller.odt

While that information is really important, there is more than that is needed to configure the motor on the firmware and get it working.

Woly · May 27, 2021

I would like to contribute to this project but enerprof wants 50 euro to ship to the USA. I am unable to find a v2 controller anywhere else. Anybody know of any cheaper options?

@michih you have a pm.

casainho · Jun 10, 2021

I am start to look at the SHUNT resistor voltage amplification factor and signal, and I found something very strange - as seen on the picture, the opamp is the MCP6021 and the pin 4 is connected to GND and pin 8 to VDD:

However, the datasheet of MCP602x, shows:

So, if the opamp is really MCP6021, then pin 1 and pin 8 would be unconnected, but we see they are not... most probably the opamp is the MCP6022 and not the MPC6021, or am I missing something??

Elinx · Jun 10, 2021

casainho said:
....

So, if the opamp is really MCP6021, then pin 1 and pin 8 would be unconnected, but we see they are not... most probably the opamp is the MCP6022 and not the MPC6021, or am I missing something??

You know if pin 7 is also connected to Vdd.
Unconnected does mean no internal connection, so it is possible to connect what you want or shorten pin 8 and 7.
It is not possible to insert a dual to a single op-amp layout

casainho · Jun 10, 2021

Elinx said:
casainho said:

....

So, if the opamp is really MCP6021, then pin 1 and pin 8 would be unconnected, but we see they are not... most probably the opamp is the MCP6022 and not the MPC6021, or am I missing something??

Click to expand...

You know if pin 7 is also connected to Vdd.
Unconnected does mean no internal connection, so you can shorten pin 8 if you want.
It is not possible to insert a dual to a single op-amp layout

No, pin 7 and pin 8 are not shorted. My current guess is that they assembled some MPC6021 batch units knowing they are instead MCP6022 -- I think this is possible, maybe the MPC6021 factory sold them this "special" units.

TSDZ2 48v 2020 new firmware

1 kW

10 GW

1 kW

10 GW

10 GW

100 W

10 GW

100 W

100 kW

10 GW

100 W

10 GW

10 GW

100 kW

10 GW

100 kW

10 GW

100 kW

1 kW

1 kW

10 GW

100 mW

10 GW

100 kW

10 GW

Similar threads