My co-founder and I were both software engineers who got into hardware almost 6 years ago.
We had both played with a bit of arduino or hobbyist stuff in the past, but dove right into EEG and neurostimulation.
Hardware is hard like software used to be hard. When we think of hardware, we're usually caught up just in the electrical chip, transistor, firmware, IO mentality.
Maybe it's just because of what we're building (https://affectablesleep.comm) but we also have to factor in mechanical design, electrical/mechanical interfaces, material science (electrode sensors), etc.
I've learned power management isn't always about, how long does my battery last, but also, how do micro-fluctuations in voltage during use impact other sensors or other operating systems.
Hardware, for us at least, has been a significantly larger footprint than we initially would have expected. It isn't just hardware, firmware, control app. For us it's been the above, plus data-quality tooling, firmware CI, in-factory provisioning and security, the list seems to go on and on.
It's a new challenge, and has been a very fun one. It does remind me a bit of the early days of the web when we'd write our own web-server, DB connection logic, etc etc.
I would say this reading took a sharp turn from what I expected on the title, but it does make sense. There is plenty of hopeful potential in this type of public learning. The author starts off with wild intentions and eventually practically works out a solution, even though you can tell it was not quite what was envisioned.
That happens to me too, I start doing something and a result isn't the end of the learning, but a chance to repeat the experience.
1. The motor demo didn't work for me (Firefox on Android). Nice to say it was made by Claude.
2. Voltage isn't like gravity. It's literally called potential. Voltage is the water being high up on the mountain. Gravity is the gravity, which was kinda the point of the analogy, no?
3. A Tesla has thousands not hundreds of 18650s. But I guess that's a superset.
4. For motor speed, I would use P = I x V. It shows the way the two work better, and the resulting P = I^2 x R = V^2 / R. Resistance is constant.
5. PWM wasn't explained right here. You can most certainly vary the voltage without PWM, and it's not just any old modulation you want. You want a binary output so your transistors don't go linear, and you can control the average power. PWM is easy for linear scaling. But you could presumably use other modulations.
6. It's important to understand what the H bridge is doing, why it matters, and what it offers. Shoot through and dead time are important. Understanding that the microcontroller outputs X current at Y voltage, and the motor needs J current at K voltage. You could drive a small enough motor directly.
7. Could maybe do a 2-cell charger with balance leads as a usability upgrade.
8. The 2 cells in series is upwards of 8.4v which is higher than the 5.5v that USB related chips allow and 6v that their absolute max is. Would be good to understand what the power chain is to make sure nothing blows up.
I think this is a good start and always kudos to those who learn, even more to this trying to teach others. Hopefully there's a part 2 going into more very simple theory. Especially a comparison vs the L298N.
My co-founder and I were both software engineers who got into hardware almost 6 years ago.
We had both played with a bit of arduino or hobbyist stuff in the past, but dove right into EEG and neurostimulation.
Hardware is hard like software used to be hard. When we think of hardware, we're usually caught up just in the electrical chip, transistor, firmware, IO mentality.
Maybe it's just because of what we're building (https://affectablesleep.comm) but we also have to factor in mechanical design, electrical/mechanical interfaces, material science (electrode sensors), etc.
I've learned power management isn't always about, how long does my battery last, but also, how do micro-fluctuations in voltage during use impact other sensors or other operating systems.
Hardware, for us at least, has been a significantly larger footprint than we initially would have expected. It isn't just hardware, firmware, control app. For us it's been the above, plus data-quality tooling, firmware CI, in-factory provisioning and security, the list seems to go on and on.
It's a new challenge, and has been a very fun one. It does remind me a bit of the early days of the web when we'd write our own web-server, DB connection logic, etc etc.
I would say this reading took a sharp turn from what I expected on the title, but it does make sense. There is plenty of hopeful potential in this type of public learning. The author starts off with wild intentions and eventually practically works out a solution, even though you can tell it was not quite what was envisioned.
That happens to me too, I start doing something and a result isn't the end of the learning, but a chance to repeat the experience.
Thoughts as a computer engineer:
1. The motor demo didn't work for me (Firefox on Android). Nice to say it was made by Claude.
2. Voltage isn't like gravity. It's literally called potential. Voltage is the water being high up on the mountain. Gravity is the gravity, which was kinda the point of the analogy, no?
3. A Tesla has thousands not hundreds of 18650s. But I guess that's a superset.
4. For motor speed, I would use P = I x V. It shows the way the two work better, and the resulting P = I^2 x R = V^2 / R. Resistance is constant.
5. PWM wasn't explained right here. You can most certainly vary the voltage without PWM, and it's not just any old modulation you want. You want a binary output so your transistors don't go linear, and you can control the average power. PWM is easy for linear scaling. But you could presumably use other modulations.
6. It's important to understand what the H bridge is doing, why it matters, and what it offers. Shoot through and dead time are important. Understanding that the microcontroller outputs X current at Y voltage, and the motor needs J current at K voltage. You could drive a small enough motor directly.
7. Could maybe do a 2-cell charger with balance leads as a usability upgrade.
8. The 2 cells in series is upwards of 8.4v which is higher than the 5.5v that USB related chips allow and 6v that their absolute max is. Would be good to understand what the power chain is to make sure nothing blows up.
I think this is a good start and always kudos to those who learn, even more to this trying to teach others. Hopefully there's a part 2 going into more very simple theory. Especially a comparison vs the L298N.
Hardware is slow