I've been very quiet on the internet lately — I bought a new house, I've been working on a ton of projects, and I've been (happily) swamped teaching in the Electrical & Computer Engineering department at my university this year.
In the fall, I taught an Advanced Embedded Systems special topics elective, and this spring, I taught the Introduction to Embedded Systems course.
I wanted to write up a few notes explaining how I changed our Embedded Systems class this semester to help others interested in Embedded Systems education.
What is Embedded Systems?
When you think about it, Embedded Systems is one of the strangest classes in an Electrical Engineering curriculum. Most classes taught to freshman and sophomores focus on applying analysis techniques to pre-designed systems:
Calculate the current going through resistor
Determine the output impedance of the amplifier< /em>
Find the 3dB frequency of the low-pass filter
Determine if the given system is causal
At the junior/senior level, students are asked to design/evaluate systems.
Design an operational amplifier circuit that amplifies a microphone with a 4.7 kOhm output impedance by a factor of 100, and provides an output impedance less than 100 ohms.
Design a buck converter that can supply a 5V 1A load from a 12V input.
Design an FSK communication system that can operate at 22 Mbps with a BER of 10^-4.
Embedded Systems isn't well-grounded in fundamental concepts; rather, it often serves as the application of all the above concepts into real-world systems. And it's not because embedded systems are the end-all/be-all of electrical engineering — rather, because embedded systems are the simplest real-world examples of these fundamental principles of EE.
Also, whi le we teach students how to design embedded systems, designing this stuff is more about following the Design Process — not using a formula to select the optimal bias resistor value for an amplifier (which is what most EE students think of when they think of "design").1In many ways, the Design Process is much more abstract and challenging than typical EE design problems. It's also much more wishy-washy, which makes many professors uncomfortable teaching it.
Obligatory Bloom's Taxonomy graphic.
Embedded Systems is messy; messy means memorization.
It is the practical application of fundamental skills where things get messy. That means embedded systems are messy, and Embedded Systems is a messy course. If you think about it, the messier something is, the more that learning outcomes will fall und er recall and recognition — rather than analysis and evaluation.
That may seem counterintuitive — shouldn't messy, complex systems yield (or even require) higher-order Bloom's stuff? No, quite the opposite.
Think of a microcontroller blinking an LED attached to a GPIO pin. If we used analysis-oriented cognitive processes instead of "lower order" thinking, we couldn't blink an LED attached to a GPIO without applying KVL/KCL, Ohm's Law, and nonlinear models of transistors. We'd have to do this for every transistor in the microcontroller. Otherwise, we would have no idea if it would "work" or not.
Of course, we don't use bottom-level analysis techniques to blink an LED. Instead, we teach students to memorize that a push/pull GPIO output cell will attempt to drive a pin to VDD or GND depending on the GPIO's register value. We teach students to memorize that GPIO pins can only supply a certain amount of current, so you can't drive large loads. We teach students to memorize that if their GPIO pin doesn't work, they probably forgot to make it an output. We teach students to memorize that each GPIO pin is part of a GPIO port, which is controlled by a single register. We teach students to memorize that some MCUs allow you to read and write individual bits in registers, and some architectures don't, and some only let you modify bits in some registers, but not others. We teach students to memorize the names of the GPIO registers for their specific MCU, and we teach students to memorize the steps necessary to compile, assemble, program, and debug their software.
All of these are abstractions — which are good. Abstract reasoning is good. But let's not forget that abstract reasoning relies on a ton of memorization and recall. As soon as you abstract something out of your mental workspace, you have to remember how it works.
Embedded Systems education should use pedagogical approach es that are proven winners when it comes to recall-oriented learning.
Matching the Pedagogy with the Learners
Alright, so we've established that any practical Embedded Systems course will be heavily rooted in recall, recognition, understanding, and application. And design/evaluation work in Embedded Systems is generally less concrete than in our circuits classes. We need to take these ideas and form a pedagogy that also links up with our students.
From a course scaffolding perspective, sophomore ECE students have taken a one-hour-a-week C programming course, where they seemed to learn to do little more than malloc() character arrays on a UNIX server and print them. These students have not (nor will ever) take a computer architecture course, and they won't take a digital logic design class until their junior year.
As an educator, I have to be cognizant of this when planning learning outcomes and pedagogy for the course. Here's what I came up with:
Use a reverse classroom approach, with online interactive reading assignments. These are the gold standard for low-order learning tasks in modern education circles. This approach allows us to cover a huge amount of content in a short time, so we can get students caught up on architecture, programming, and digital logic at the same time they're doing embedded development.
Use project-based learning for higher-order learning. Having students practice conceptual topics with real hardware is critical to seeing how these topics apply to real-world embedded engineering, and it gives students the opportunity to practice the design process.
Use regular in-class quizzing as a summative assessment. These quizzes are the primary grade component for the students' official records.
Online Reading Assignments
An example snippet out of the GPIO output reading assignment.
I experimented with a traditional lecture format when I taught Advanced Embedded Systems last year, and it was extremely inefficient at handling the learning outcomes of the class.
For my Intro course last semester, I decided to use a reverse classroom. Reverse calssrooms are not where students teach the instructor (though that's cool too!) — but rather, where students do "classwork" (learning) at home, and "homework" (p racticing their learning) in class.
A lot of reverse classrooms have instructors record lectures and post them online for students to watch, and then bring questions to class. Instead, I generally use interactive reading assignments that I create on our university's LMS.
Before each lecture, students work through the assigned reading and answer the built-in questions. In class, we often review the results of the reading assignment to see which questions students bumped on the most. We go through questions students have about the assignment, and then we spend the remainder of class time reinforcing these topics with peer learning exercises, demonstrations, other group work, and tons of question-and-answer time.
For what it's worth, certain lectures — especially on electronics circuits — demanded a true lecture-style reading assignment, so I ended up creating a few Khan Academy-style videos.
I really try to avoid introducing new material in lecture s — more progressed students fall asleep, and emerging learning struggle to keep up. Instead, the reading assignments provided an amazingly efficient way for students to achieve learning outcomes.
The interactivity is key: Over-confident students who would otherwise brush through a reading — skimming over important details, only to be punished on a homework or quiz — are forced to re-read and think about details they omitted when they are asked questions about the material. By interspersing questions in between content instead of having students fill out separate quizzes, the questions serve as a speed bump that forces students to avoid rushing through material.
Plus, when students are finished with their reading assignment, they get instant feedback on their learning progress. This feedback cycle is critical to learning; many students would bring questions to class that were based on reading assignment questions they missed.
This is the whole goal of a rever se-classroom approach; we get to reinforce and strengthen learning in the classroom, instead of trying to do this outside of the classroom.
Course Roadmap: Top-down, JIT, and Corkscrew Learning
We spent our first week block-diagramming real-world embedded systems — mostly focused on consumer electronics products the students see in their own lives. The reading material presented very high-level explanations of a microcontroller, an IC, a circuit board, the basic peripherals inside the microcontroller, and how these things are generally tied together.
You may be surprised how little material students must learn before they can start making good-quality predictions about how products are designed. Two lectures in, students were block-diagramming ovens, gaming controllers, calculators, and electric drills.
Sure, their ovens had heating elements directly attached to DACs, and their electric drills neglected a forward/backward switch, but I was amazed at the e arly models students constructed in their brains about embedded systems. They know that buttons are hooked up to GPIO pins. They know that many displays require a display controller to sit on a communications bus, and they know that, as one student said, "I2C is cool because you can put multiple sensors and things on it." Not bad for the first week of class!
Traditionally, instructors of this course presented material bottom-up, topic-by-topic. First, an introduction to binary. Then, a C programming review. After that, GPIO. Then ADCs. Then timers. Then UART/SPI/I2C. Et cetera.
This is extremely convenient for the instructor — they can work out all the learning outcomes relevant to each topic, and pound them out methodically.
Instead, I'm a big fan of JIT (just-in-time) learning, and what I call the corkscrew approach: circling back around through the same material, over and over again, each time digging deeper and uncovering more details (and exce ptions to the rule, in the case of embedded systems).
As an example: I wouldn't feel comfortable graduating a student from my course without them being able to explain output impedance of a GPIO pin. However, I don't need them to have mastery of this to turn an LED on or off, or as a pre-requisite for operating a UART. We can cover a "first pass" through GPIO, then move onto other peripherals and, later on in the semester, circle back around to output impedance.
So how do you know when to provide instruction for a topic? We do most everything just-in-time (JIT). By the third week, we hadn't covered conditional statements or binary operators in C, but we've worked through pointers (including a challenging reading assignment problem). Why? Because their first GPIO assignment will require that they can modify memory using C programming. And that's about all it will require. We didn't get to output impedance until we discussed PWM, since so many PWM applications students consider involve driving high-power loads.
But JIT doesn't just describe the order of topics; I use it to provide real-time feedback on reading assignment questions. I will often configure our LMS's "wrong" answers to provide additional instruction to students who misunderstood a concept. That way, answers aren't simply "wrong" — there's a learning component built into the question itself. Students are eager to complete the reading and get immediate feedback on what they have and haven't mastered. This JIT feedback is so much more powerful than traditional paper-and-pencil formative assessments, where the students may get their quiz back a week or more later, with nothing more than a grade and perhaps the correct answers circled.
Don't avoid details
One fault I see with some embedded systems curricula is to strive for affective engagement by simply throwing in the towel and converting their classes into something that w ould belong at a makerspace. They end up with course material that has very little relevance to the actual learning outcomes for the course, and instead focus on things like hobby servo motors, 3D printing, and driving WS2812s with Arduino libraries. This is fun stuff to play with — I encourage my students to take up electronics as a hobby. But this stuff doesn't belong an embedded systems classroom, where we have so little time to cover such a huge amount of information.
I think a lot of instructors end up equating "top down" with "stay out of the weeds" — that's simply not true, though (otherwise the word "down" would not appear in "top down").
Because of all the harsh sentiment expressed about "the dirty low-level details" my initial gut feeling was that students would get excited about the high-level stuff and snooze during the low-level details. However, something quite different ended up happening in the classroom.
In the third wee k of class, I introduced GPIO (and, really, the concept of memory-mapped peripherals) to my students by typing out the bare op-codes of a "blinky" program in the hex editor programming tool, uploaded the code to an 8051 MCU, and ran it in front of the class. I expected quite a bit of snoozing, but instead, many of them were absolutely enthralled.
I could see that the material clicked in their brains instantly. They finally put the pieces together that we had been talking about: all compilers do is turn C code into these primitive machine instructions, and a GPIO port is just a register sitting in memory space somewhere. They know there's no such thing as a "set pin high" CPU instruction, since they saw nothing but "MOV" and "JMP" instructions.2Here, the 8051 was super useful — the fully orthogonal instruction set let me write an entire blinky program in something like 5 bytes of code. There's nothing wrong with doin g classroom demos using microcontrollers other than the one found in the lab kit — in fact, it can help strengthen learning.
When a student came to me later that week, unsure of why her breakpoint was "broken" in the lab she was working on, I reminded her to look at the disassembly view, and she quickly noticed, "oh weird, the compiler didn't emit any instructions for that line of code. No wonder." Those sorts of realizations don't usually happen in the third week of an embedded systems class because instructors are afraid of diving into the deep end.
Learners need a concrete understanding of how these systems work at all levels to feel comfortable and confident. They like the details, and they can even get excited by them — just as long as they've been primed to see how these details come together to create amazing outcomes.
Us more experienced folks are better at abstraction; we can comfortably and confidently use systems that we don't fully understand. We have to fight the urge to teach topics that way.
Project-Based Learning
In addition to reading assignments, there's a project-based learning (PBL) component to my course. This is somewhat comparable to traditional "lab assignments" found in other Embedded Systems courses (and I even refer to them as "labs" in class), but they end up serving different goals and function differently in a pedagogical sense.
The old labs for the class were weighted strongly enough that I'd consider them summative assessments: students were expected to show up to lecture, learn how to use their microcontroller by staring at the lecture slides while the instructor went over things, and then demonstrate their achievement by programming the lab, writing a report, and turning it in for credit.
These labs, which used Arduino, were things like:
Use Serial.print() to experimentally determine the size of various data typ es.
Time a GPIO pulse with a logic analyzer or oscilloscope to estimate how many clock cycles it takes to write a value to a port.
Read a UART character, "encrypt" it using a shift cypher, and send it back to the computer.
I don't know how other universities handle embedded labs, but I found these to be very bizarre — they have an oddly experimental/investigative tone to them; they seem to view the microcontroller as a black box, whose properties we can discover only through experimentation 3This may seem similar to other classes in an undergraduate EE curriculum, though it's missing a big point — in those other classes, students calculate what a property should be, and then experimentally verify. It reinforces to students that we can form models of systems that help us predict behavior without having to actually observe the behavior experimentally.
Students leave the class thinking the only way of s eeing how quickly a UART interrupt can work is by trying it and timing it with a scope.
To make matters worse, the labs are often extremely prescriptive (with literal step-by-step instructions that guide the student precisely through every task), yet ask complex questions that aren't explored in lectures or lab material. Sadly, these questions often represent the kernel of what the lab is about — they're the stuff the student should leave the class understanding.
For example, in their lab reports for the GPIO lab, students are expected to explain why wiggling a GPIO pin in a while() loop does not produce a 50% duty cycle. That's how the question is framed. This requires them to have a high-order understanding of cycle-by-cycle timing of machine instructions without having ever looking at a disassembly of their C source code, or taught about computer architecture.
I've never graded those labs, but I'd imagine I'd see very poor-quality answers fro m the students.
Revising the Lab Kits
When I started thinking about what I would change about the class, one of the first things to go was the Arduino platform it was taught with.
I honestly have no idea why Arduino is used as much as it is in EE / CS embedded education programs, since it has such poor alignment with most learning outcomes for these classes:
Difficulty accessing dev environment internals: how do I view the assembly code output from Arduino? Or the hex file that will get programmed? Can I control how variables are placed in RAM, or configure the linker or compiler optimization settings in any manner?
Difficulty accessing hardware internals: there's no debugger. It's insane to teach an embedded systems course with a platform that does not allow you to set breakpoints or inspect or modify memory.
Strange, non-standard C preprocessor secret sauce: "void main()"? Nah . Call functions without declaring them first? Sure. Wait, what headers are included by default? Who knows. Students leave the course thinking that DDRB, Serial.print() and uint16_t are all reserved words in C that you can use anywhere.
My other (more pragmatic) issue with the Arduino platform is the nonstandard tooling. There are tons of MCUs students will encounter professionally. These generally all work the same: you write software in C, and then you compile it, getting some sort of hex file. You use a debugger or a programmer to communicate with the MCU and load the program code into the flash memory of the microcontroller, and then you run it. Most of the time, you have a debugger attached that can set break points, inspect memory, and receive trace data. The Arduino Uno ecosystem is not representative or similar to any other microcontroller ecosystem, so it seems like a bizarre choice.
With the Arduino out, it was time to go M CU shopping. I approached the course as yet another engineering problem: you need to pick the right part for the job.
Microchip PIC16
For the project-based learning component of the course, I selected the PIC16F18446 + MPLAB Snap debugger. This is not a microcontroller I would generally use in my professional work, so why teach this course around the PIC16?
DIP package allows students to breadboard their MCU to remove any "black box" concerns that come with dev boards
Simple peripherals
Extremely easy-to-read datasheet with step-by-step directions to configure peripherals
Low-cost ($15) debugger
Free IDE that runs on Windows, macOS, and Linux
Decent IO viewer in the IDE that allows students to interact with peripherals (and potentially see why their code isn't working)
Toolchain supports bitwise operations with fluent syntax (RB5 = 1 sets pin RB5 high, without touching other GPIO pins)
Pe ripheral code-gen tools built into the IDE
Lots of breakpoints (3? 4?) compared to other PIC parts
I looked at literally every MCU I reviewed in the round-up, and I think I made the best decision. Many deal-breakers to consider:
The Texas Instruments MSP430 LaunchPad FET doesn't seem to work in macOS. I find the MSP430 datasheets to be far too cerebral, and the clock architecture is a bit too complicated for beginners.
The Silicon Labs EFM8 ticks off almost all the checkboxes above, but you can't do any GPIO operations without enabling the Crossbar, which is confusing for students new to memory-mapped I/O. No DIP package either means I'd have to have students solder SOICs onto adapter boards, or use old-stock C8051 parts.
The clock system and power gating on most Arm parts is way too complicated for students new to MCUs to understand, so that excludes a huge number of parts.
Other MCUs often don't have dev environments f or macOS or Linux. Any student serious about embedded systems needs to have a Windows computer (for the CAD software alone), but our department doesn't have specific computer guidelines, and students get mixed messages from other instructors in the department that work outside of the embedded systems field.
For what it's worth, the PIC16F18446 is not without its problems:
Programming and debugging speed is atrocious. This isn't an MPLAB Snap problem — it's just the PIC16. Students learned to be a bit more methodical when they were developing: measure twice, debug once.
Peripheral Pin Select is clunky and error-prone for beginners. My students quickly learned of the spectrum between "easy" and "flexible" — while I like that students can route any function to any pin, there are a few gotchas that can be maddening to figure out. For example, when programming the MCU as an SPI master, you have to route the SCK pin as both an output from the MSSP peripheral, and also as an input back into the MSSP peripheral.
ANSEL is mis-named. Why would you have to modify a register named "Analog Select" if you want to use a GPIO pin as a digital input? Well, because, "ANSEL" doesn't really mean "enable analog" — it means "disable the digital input buffer." At least the PIC16 doesn't use backwards GPIO data direction values like the AVR.
Weird interrupt syntax. Students struggled to understand why you had to write "__interrupt()" — which looks like a function — as a modifier to their ISR. Students would often declare a function with this name, and end up with bizarre code compilation errors.
IO View is broken half the time. If you want to inspect peripheral registers in MPLAB X, IO View seems like a good place to do it. Unfortunately, in my experience, its values often get fr ozen. There's nothing worse than students not being able to trust their tools.
New Format
In my class, each lab has an experimental component and a PBL component.
Experimental Component
The experimental component is where students learn how to use a peripheral or microcontroller component. As an example, let's look at the GPIO lab. I didn't mind the existing idea — time GPIO values with a scope to infer instruction timing — but we reworked the problem to make it a bit more realistic, while adding more thorough analysis built into the lab.
In the real world, you always know how many cycles it takes for an instruction to execute (it's clearly printed in the datasheet), but it's relatively common to make oscillator configuration mistakes that cause your MCU to run at a speed different than you think it should be running at.
As a result, I had my students write C cod e to toggle a GPIO pin, and then look at the disassembly output and step through the instructions with their debugger. They calculated the number of cycles their code should take to execute, and then compared it with the actual execution time to determine the clock frequency of their microcontroller.
By walking them through each component of this in a prescriptive manner, they practiced reading datasheets to look at instruction timing, calculated how many cycles their loop would take to execute, captured experimental data, and fit their calculations to the data.
PBL Component
Additionally, each lab has a project-based learning (PBL) component, which chips away at a semester-long design project.
I've seen a wide variety of embedded projects used in instruction — many of which fall into the category of "small toy robots" — and I wanted to find something that felt like a commercial product that a student would go out and buy. I had students prog ram a commercially-available DMX light, pictured above.
I was inspired by watching Big Clive's teardown of the light fixture. The light fixture lets students program almost all the important peripherals on their MCU:
GPIO inputs for push-button switches
I2C for the 4-digit 7-segment display driver
Timers/PWM for the main LED array
ADC for the microphone
UART for the DMX receiver
These light fixtures are very inexpensive — we bought a class set of them from eBay for something like $7 each.
I did a quick respin of the co ntrol board design — swapping out the Nuvton N76 with the same PIC16F18446 we used in the lab kit — but kept everything else the same.
It worked really well. Students were given the light fixtures at the beginning of class and they were essentially paperweights, containing a simple demo firmware image that lit each color when you pressed a button. By the end, they were fully-functional DMX lights — complete with extra features and capabilities the students designed and implemented on their own in the last few weeks of class. One of my students uploaded a YouTube video illustrating how these projected turned out.
There was a lot of other learning that was happening undercover; students had to disassemble and reassemble their light fixture whenever they wanted to program the board. They got into the habit of how everything goes together, and what cable plugs into what. They saw that there's nothing magical inside a plastic enclosure for a product, and they started building confidence — feeling like they were a lot closer to being able to design this stuff than they ever thought before.
Summative Assessment
I do not use projects/labs for summative assessment. Students need the freedom to work with others (and me and my TA) on the projects since a lot of reinforcement happens while they're working on things. Plus, projects and labs focus on different orders of learning than the reading assignments do, so if you use the labs for summative assessment, you're testing students over material they have yet to be formatively assessed on, which is unfair to them, and prevents the instructor from providing learning interventions before the assessment.
As a result, it makes more sense to use the PBL component as additional formative assessment in conjunction with the reading assignments — both covering different areas of learning. If you're shaky on formative versus summative assessment, all you need to know is that formative assessments serve as diagnostic tools that students and instructors can use to evaluate learning along the way. Summative assessment is used to evaluate achievement.
At the end of the day, I have to assign a grade to each student in my class, and I want that grade to ultimately reflect achievement — not effort.
As a result, I designed several small tests that I administered in class roughly every two weeks. These summative assessments had roughly 10 short-answer and multiple-choice questions on them; they were always conceptual in nature, so students with good understanding of the material could complete them in as much time as it took to write out the answers.
Students who couldn't complete them immediately generally had much worse scores, so there's not much point in giving students more than 10-15 minutes to finish. Even so, I allo w students as much time as they'd like to complete the assessment, just so students don't feel unfairly treated or rushed.
Wrapping Things Up
It was an eye-opening year teaching both of the Embedded Systems classes, and we're about a month away from kicking off the fall semester, where I'll be teaching my Advanced Embedded Systems class again (which, itself, will be completely different than last time around).
Teaching isn't complicated; it can be approached just like an engineering problem — broken into small pieces and thought out. Once the pedagogy is working, it's fun to dial things in and optimize your course. As an example, if I teach my Intro class again, I'm going to be thinking about how I can minimize the amount of one-on-one time students had to spend with me in office hours to be able to work through the material; there's a lot of JIT intervention papers I've been reading, and I have tons of ideas floating around.
I'd love to hear what other instructors who teach Embedded Systems do in their classes — there's far too few published studies on Embedded Systems education, and few instructors block about this stuff. Let's get the conversation going!
In many ways, the Design Process is much more abstract and challenging than typical EE design problems. It's also much more wishy-washy, which makes many professors uncomfortable teaching it.
2.
↑
Here, the 8051 was super useful — the fully orthogonal instruction set let me write an entire blinky program in something like 5 bytes of code. There's nothing wrong with doing classroom demos using microcontrollers other than the one found in the lab kit — in fact, it can help strengthen learning.
3.
↑
This may seem similar to other classes in an undergraduate EE curriculum, though it's missing a big point — in those other classes, students calculate what a property should be, and then experimentally verify. It reinforces to students that we can form models of systems that help us predict behavior without having to actually observe the behavior experimentally.
Las reacciones de fusión nuclear son bastante comunes en la naturaleza, aunque no en la Tierra. Son la fuente de la energía generada por el Sol y los miles de millones de estrellas en todo el Universo. En cierto sentido se puede decir que la energía de fusión es la principal fuente de energía de la naturaleza [1]. En las estrellas el confinamiento del plasma lo logra la atracción gravitacional.
Uno de los aspectos más fascinantes de la física nuclear es el estudio de las reacciones de fusión en los diferentes tipos de estrellas. Estas reacciones son las que terminarán formando muchos de los elementos químicos [2]. El Sol es un buen ejemplo.
En el Sol, el proceso de fusión da como resultado la producción de un núcleo de helio a partir de cuatro protones. El resultado neto de las reacciones que tienen lugar se puede escribir como
donde +10e es un «anti-electrón», también conocido como positrón. Esta reacción neta no tiene lugar en un solo paso, sino que se puede llegar a ella a través de diferentes conjuntos de reacciones cuyos resultados netos se resumen en esta ecuación. En cualquier caso la cantidad total de energía liberada es siempre la misma: 26 MeV. La fusión de cuatro protones para formar un núcleo de helio es la principal fuente de energía del Sol.
El hidrógeno y el helio juntos constituyen alrededor del 99% de la masa del Sol, con aproximadamente el doble de H que de He. Afortunadamente, hay suficiente hidrógeno como para que el Sol siga suministrando energía durante varios miles de millones de años más.
¿Mediante cuál de los varios conjuntos posibles de reacciones tiene lugar la transformación del hidrógeno en helio? Tenemos que descartar el proceso directo de colisión de cuatro protones para formar un núcleo de helio no porque sea imposible, sino porque la probabilidad de una reacción así en las condiciones del interior del Sol es demasiado baja. Es decir, puede suceder, pero no con la suficiente frecuencia para generar la cantidad de energía liberada que se observa.
Un conjunto de reacciones más probable es el siguiente: cuando la temperatura es de aproximadamente 107 K, las energías cinéticas son lo suficientemente grandes como para superar la repulsión eléctrica entre los protones y se produce la fusión de dos protones. La reacción nuclear da como resultado un deuterón (hidrógeno-2), un positrón y un neutrino. Tan pronto como se forma el deuterón, reacciona con otro protón, dando como resultado helio-3 y un rayo gamma. Los núcleos de helio-3 se fusionan entre sí, formando partículas alfa y dos protones. En cada una de estas reacciones, se libera energía, lo que da como resultado 26 MeV para el ciclo completo de cuatro protones que dan lugar a un núcleo de helio.
La velocidad de la reacción depende del número de núcleos por unidad de volumen y de la temperatura. Cuanto mayor sea la temperatura, más rápido será el movimiento térmico de las partículas y más frecuentes y enérgicas serán las colisiones. A la temperatura del interior del Sol, que se ha estimado que está entre 10 y 20 millones de grados, las energías cinéticas resultantes del movimiento térmico están en entorno de 1 keV.
Notas:
[1] Decimos en cierto sentido porque existen otras formas de energía, como la energía oscura o, incluso, la atracción gravitatoria de los agujeros negros. Pero no las consideramos.
[2] De aquí viene la expresión "somos polvo de estrellas", porque los elementos que nos componen se crearon en su mayoría por procesos de fusión en las distintas fases de la vida y muerte de diferentes tipos de estrellas.
[3] Quizás convenga comentar que las reacciones químicas no pueden proporcionar energía a velocidades lo suficientemente grandes (o durante un tiempo lo suficientemente largo) como para explicar la producción de energía en el Sol. Las reacciones de fusión nuclear sí lo logran fácilmente.
Es una verdad universalmente admitida que las fuentes energéticas de la humanidad deben ser de carácter renovable. Lo que nos conduce a un uso creciente de las energías eólica y solar fotovoltaica. Estas últimas son actualmente las más desarrolladas y las más competitivas respecto a otras alternativas no sostenibles.
La forma práctica de usar estas fuentes de energía es su transformación en electricidad. Por ello, cualquier país suficientemente avanzado tenderá a la electrificación del sistema energético en los próximos años.
Sin embargo, la gestión de una red eléctrica basada en energías renovables no es sencilla, dado su carácter intermitente. No solo hay que gestionar el ciclo día-noche de la solar fotovoltaica, sino también los ciclos estacionales verano-invierno.
Es necesario almacenar la energía en periodos en los que existan excedentes. De esta forma, se podrán usar en momentos en los que la disponibilidad de energía es menor (menos viento o menos radiación solar en invierno).
Existen diferentes métodos de almacenamiento de energía eléctrica, como las baterías o el bombeo hidráulico. La mayor parte de ellos no permiten cubrir la demanda necesaria o no permiten el almacenamiento a largo plazo de grandes cantidades de energía. Pero existe un vector energético que sí permite ser almacenado y distribuido cumpliendo estos requisitos: el hidrógeno.
Producción y almacenamiento del hidrógeno
El proceso de producción de hidrógeno a partir de la energía eléctrica es conocido como electrolisis. Se realiza aplicando corriente eléctrica al agua, separando así sus elementos: hidrógeno y oxígeno. De esta forma, la electricidad renovable producida se almacena en forma de hidrógeno.
Cuando es necesario disponer de nuevo de electricidad, es posible realizar el proceso inverso: alimentando una pila de combustible con el hidrógeno almacenado se obtiene la electricidad que requerimos, produciéndose también agua.
Existen diversas formas de almacenar hidrógeno, pero la más utilizada actualmente son los depósitos a alta presión. La presión estándar de almacenamiento es 700 bar (unas 700 veces la presión atmosférica). Su uso es seguro gracias a los avances de los últimos años en tecnología de materiales. Podemos almacenar grandes cantidades de energía durante largos periodos de tiempo y, por tanto, gestionar la red eléctrica.
Más allá de la electricidad
Existen otros usos de este hidrógeno renovable diferentes de la electricidad, como los de empresas que requieren calor industrial de calidad. Incluso es posible usar la red de distribución de gas natural inyectando en ella gas de origen renovable.
Esquema de almacenaje y distribución directa (línea azul) o a través de la red de gas natural (línea roja) de hidrógeno renovable. Fuente:International Renewable Energy Agency (IRENA)
La eficiencia de los electrolizadores y las pilas de combustible suele ser alta, entre el 70 y 90 %, dependiendo de la tecnología usada. El uso directo de la electricidad renovable no tendría ninguna pérdida. Pero, si es necesario almacenarla, la tecnología del hidrógeno resulta ser la más efectiva.
Aplicaciones en transporte
Las primeras aplicaciones del hidrógeno como vector energético se están produciendo en el sector del transporte. Desde 2015 existen en el mercado vehículos eléctricos, como el Toyota Mirai o el Hyundai Nexo.
En los coches, la electricidad se produce en una pila de combustible alimentada por un depósito de hidrógeno. El repostaje del hidrógeno se realiza en una estación se servicio de forma muy similar a como se realiza con otros combustibles. Un tiempo de repostaje de entre 3 y 5 minutos permite una autonomía cercana a los 700 km.
Países como Japón (con más de 100 estaciones de servicio de hidrógeno) o Alemania (con 50 estaciones de servicio) se encuentran a la vanguardia de la tecnología.
Recarga del depósito de un Hyundai NEXO. Fuente:Hyundai
Aunque en Europa se considera una tecnología prioritaria desde hace unos años, en España no existe aún ninguna estación de servicio de hidrógeno abierta al público de forma similar a como existen en otros países europeos. Desde la Asociación Española del Hidrógeno estamos trabajando para que esta situación cambie.
¿El futuro ya está aquí?
La tecnología ha llegado a su desarrollo comercial en esta última década. Pero los próximos años traerán las mejoras necesarias para que su expansión sea posible.
El precio actual de la producción de hidrógeno se sitúa en unos 8 €/kg y el depósito de los vehículos comerciales contiene unos 6 kg de hidrógeno. Esto supone que el precio de llenar un depósito es similar al de la gasolina o el diésel. Sin embargo, el coste del hidrógeno disminuirá aún más en los próximos años.
En los Juegos Olímpicos de 2020 en Tokyo, la organización ha apostado por un transporte eléctrico basado en el hidrógeno. Será un gran impulso para esta tecnología y un incentivo para que los costes sean aún más bajos.
También se esperan mejoras en la tecnología de la electrolisis del agua y en la aplicación práctica de otros procesos nuevos, como la fotólisis directa del agua con luz solar.
En busca de materiales alternativos
Las nuevas tecnologías suelen generar un problema de aumento de la demanda de materiales estratégicos. Éstos son materiales escasos o que se producen en pocos lugares en el mundo. En el caso de los coches eléctricos de baterías, el litio y el cobalto son los materiales estratégicos. Para los electrolizadores y las pilas de combustible, es el platino. Aun así, la cantidad necesaria de platino no es muy superior a la de metales nobles de los tubos de escape de los vehículos de combustión interna.
Los grupos de investigación que trabajamos en estas tecnologías tenemos en cuenta este problema. Estamos empezando a tener éxito en el desarrollo de materiales alternativos al platino que sean abundantes y sostenibles. Muy probablemente, los sistemas electroquímicos de los vehículos eléctricos del futuro serán muy diferentes a los actuales.
Una última consideración: la mayor parte del hidrógeno producido actualmente se obtiene a partir de combustibles fósiles. Esto no encaja en el esquema de sostenibilidad descrito en este artículo. Pero en los próximos años veremos cómo se usarán cada vez más las fuentes de energía renovables. El hidrógeno tendrá un papel fundamental en esta transición.
Microchip's latest software release addresses operators' evolving requirements with respect to signal fortification It is essential for security technologies for commercial and military operators to avoid service interruptions Microchip Technology has announced a major software update for its BlueSky GNSS Firewall product, thus providing a higher level of resiliency against GPS vulnerabilities for critical infrastructure […]
Pocket PCs and PDAs were all the rage back in the late '90s and early 2000s, because they let you check your calendar, send emails, and browse the web on the go without lugging around a laptop. But, they quickly became obsolete with the introduction of smart phones and tablets. Now they just might make a come back thanks to this Indiegogo campaign for the 5" touchscreen Mi Mini PC.
Why would you want a pocket PC when you most likely already have a smartphone in your pocket right now? The main reason is that it runs Windows 10, so you're getting a full-fledged desktop OS instead of a mobile OS that is full of limitations. For power users, that means you can use it as a terminal for doing server work. Gamers can play PC games on the go, and there is even a snap-on gamepad accessory specifically for that purpose.
The Mi Mini PC is just $149 for super early birds, but it's packing a surprising amount of power under the hood. There is a 5" touch screen, a 2.56GHz Intel Atom® x7-Z8750 processor with four cores, 8GB of RAM, and a 128GB SSD. There is also a lot of connectivity: an HDMI port, USB 3 port, USB-C port, Ethernet port, Wi-Fi, and Bluetooth. Essentially, you're getting everything you'd find in a budget laptop, but in a package that fits in your pocket.
The campaign is already well past its funding goal, and still has 22 days left to go. There are even a number of upgrades available if you want better specs. Backers can expect to receive their Mi Mini PCs in September.
Krunal A. Shah, Director of Subodh Tech Private Limited (Self-owned).
University graduates and professionals sometimes talk about not being selected in an organization despite having good academic records, required skill sets and communication skills.
As per my observation and experience, gone are the days when organizations were only looking for good academic records and technical skills. I am not saying that technical skills and good academic records are not required. Technical skills are required as that make us job-ready and good academic records reflect sincerity of candidate. In addition to both of these, nowadays Emotional Intelligence plays a vital role to get selected in an organization.
What is an Emotional Intelligence?
Emotional Intelligence is an ability of an individual to understand emotions of self and emotions of others. A person with emotional intelligence can effectively express own emotions and control them. He can understand others people emotions and can interact with them more effectively. For example, a subordinate having low self-esteem requires a timely appreciation for the work he carried out successfully by his team leader.
A couple of years back to take a leap in my career I was going through skills required in one of the Multinational Company. In that, I found "Conflict Management" as one of the key skill requirement. An emotionally intelligent person can effectively manage conflictions with the customers, which could turn out to be beneficial for the company in terms of maintaining customer relationship.
Here are some few reasons that an organization requires to have emotionally intelligent employee:
An emotionally intelligent employee can work effectively in a team.
Can be more transparent and be open for communication.
Adaptability to change in work environment.
Emotionally intelligent employees know their strengths and weaknesses.
Empathy for other people's feelings. Such employee can build a good relationship with co-workers and customers.
Emotionally Intelligent employees have great self-esteem. Employees having great self-esteem probably do not compare themselves with others. Comparison in any way is not at all positive. Comparison generates energies like jealousy, insecurity, and even guilt sometimes within the person. These energies are very negative and thus creates negative work environment.
Can work under stressful situations.
An emotionally intelligent employee keeps a friendly relationship. This thing I have observed when current Honourable Prime Minister of India Mr. Narendra Modi was addressing board exam students of India. Before starting his speech, he said students to consider him as their friend and not the Prime Minister of the country. Friendly relationship opens up the communication between two individual.
How to Cultivate Emotional Intelligence?
There are few strategies to improve emotional intelligence as mentioned below:
Meditation
This is my personal experience. Meditation increases emotional intelligence. Stress releases hormones like Cortisol, which reacts, with our good hormones. Doing meditation in an effective way balances the required hormones in our body and nullifies unwanted hormones. To accomplish any work and to combat any harsh situation we must have a higher energy level, which can be achieved by meditation.
Increase self-awareness
We should learn to monitor our reactions to situations we are facing. We must honestly analyze our strengths and weaknesses. Focusing on strength and improving weaknesses is the key to success.
Learn to react
I have observed in my career that some team leaders' outburst their emotions on their subordinates due to work pressure. Doing this, they plummet their credibility. Researchers have proved that those who practice meditation effectively can work under stressful conditions with ease. Effective mindfulness practice makes our mind to work at moderate speed. We can choose our thoughts and react accordingly. I have observed this in my ex-team leader. He never scolded us badly for mistakes we had committed no matters how much big they are, he usually finishes off saying, "don't repeat again".
Listen to others
An emotionally intelligent employee listens and understands the emotions of another colleague without judging them in a negative manner. Team leaders having this habit allows them to connect with their subordinates.
Motivate others
An emotionally intelligent leader help his subordinates to work with their strengths and improve weaknesses. He gives timely appreciations to his subordinates to keep them motivated for the work they are doing.
How do organizations assess candidate's Emotional Intelligence?
Behavioral questions are asked by the interviewer to assess the emotional intelligence of the candidate.
There is quite a long list of behavioral questions out of which few of them are listed below:
What are strengths and weaknesses? What do you do to overcome your weaknesses?
What motivates you to do work?
Have you been criticized? If yes, how did you tackle it?
How would you describe yourself?
Have you worked in a stressful situation? How have you tackled that situation?
Who is your role model and why?
If you have been provided two tasks how you would decide which one to be given priority?
Reference
Daniel Goleman, "Emotional Intelligence – Why it can matter more than IQ?", Bloomsbury.
Científicos norteamericanos han observado por primera vez, en vivo y en directo, cómo se forma un pensamiento humano en el cerebro. Basándose en la electrocortocografía, que utiliza electrodos sobre la superficie expuesta del cerebro, comprobaron cómo la corteza prefrontal es el pegamento de la cognición: allí se coordinan los procesos neuronales que permiten repetir una palabra o determinar una emoción facial.
Neurocientíficos de Berkeley han observado por vez primera, en vivo y en directo, el progreso de un pensamiento a través del cerebro, desde la fuente de la inspiración hasta la respuesta, mostrando claramente cómo la corteza prefrontal coordina la actividad para ayudarnos a reaccionar ante una percepción. Los resultados se publican en Nature Human Behaviour.
Lo han conseguido registrando directamente la actividad de las neuronas desde la superficie del cerebro mediante una técnica conocida como electrocorticografía (ECoG). Esta técnica utiliz...
Foto: NASA/JPL-Caltech/GSFC
Petrmalinak/Shutterstock
Esquema de almacenaje y distribución directa (línea azul) o a través de la red de gas natural (línea roja) de hidrógeno renovable. Fuente: International Renewable Energy Agency (IRENA)
Recarga del depósito de un Hyundai NEXO. Fuente: Hyundai
Krunal A. Shah, Director of Subodh Tech Private Limited (Self-owned).