You’d think that with as many sick people as there are in the world, it wouldn’t be too difficult for a doctor in training to get practice. It’s easy to get experience treating common complaints like colds and the flu, but it might take the young doctor a while to run across a dissecting abdominal aortic aneurysm, and that won’t be the time for on the job training.
Enter the SP, or standardized patient – people trained to deliver information to medical students to simulate a particular case. There’s a problem with SPs, though. While it’s easy enough to coach someone to deliver an oral history reflecting a medical condition, the student eventually needs to examine the SP, which will reveal none of the signs and symptoms associated with the simulated case. To remedy this, [Chris Sanders] and [J Scott Christianson] from the University of Missouri developed an open-source RFID stethoscope to simulate patient findings.
This is one of those “why didn’t I think of that?” ideas. A cheap stethoscope is fitted with an Arduino, and RFID reader, and a small audio board. RFID tags are placed at diagnostic points over an SP’s chest and abdomen. When the stethoscope is placed over a tag, a specific sound file is fetched from an SD card and played over earbuds. The student doesn’t have to ask, “What am I hearing?” anymore – the actual sound of bruits or borborygmi are heard.
We can easily see expanding this system – RFID tags that trigger a faux ultrasound machine to display diagnostic images, or tiny OLED screens displaying tagged images into an otoscope. A good place to start expanding this idea might be this digital stethoscope recorder and analyzer.
How many of you speak more than one language? Since Hackaday is an English-language site whose readership is world-wide, we are guessing quite a lot of you are not monoglots. Did you learn your second or third languages at school, and was it an experience you found valuable? How about your path into software? If you are a coder, were you self-taught or was your school responsible for that as well?
It’s been a constant of the last few decades, officials and politicians in charge of education worrying that tech-illiterate children are being churned out of schools ill-equipped for the Jobs Of Tomorrow, and instituting schemes to address the issue. One of the latest of these ideas has come our way from Florida, and it’s one that has sparked some controversy. It sounds simple enough, make coding equivalent to language learning when it comes to credits in Floridian high schools.
You might think that this idea would be welcome, but instead it has attracted criticism from those concerned that it will become an either-or choice in cash-strapped school districts. This could lead to kids without an extra language being at a disadvantage when it comes to applying for higher education. There are also concerns that the two subjects are not equivalent, and should not be conflated.
It’s difficult from the perspective of an adult technical journalist without a background in education to speculate on the relative benefits to young minds of either approach. It is very likely though that just as with previous generations the schools will discover that there is limited benefit in pushing coding at kids with little aptitude or interest in it, and that the benefits in terms of broader outlook and intellectual exercise gained by learning another language might be lost.
Which was more valuable to you at school, coding or learning a language? Were you of the generation that learned coding through BASIC from the manual that came with your home computer, and should today’s kids be doing the same with Scratch and Python on boards like the Raspberry Pi? Let us know in the comments.
It’s funny, how obsessed we are with qualifications these days. Kids go to school and are immediately thrust into a relentless machine of tests, league tables, and exams. They are ruthlessly judged on grades, yet both the knowledge and qualifications those grades represent so often boil down to relatively useless pieces of paper. It doesn’t even end for the poor youngsters when they leave school, for we are now in an age in which when on moving on from school a greater number of them than ever before are expected to go to university. They emerge three years later carrying a student debt and a freshly-printed degree certificate, only to find that all this education hasn’t really taught them the stuff they really need to do whatever job they land.
A gold standard of education is revealed as an expensive piece of paper with a networking opportunity if you are lucky. You need it to get the job, but in most cases the job overestimates the requirement for it. When a prospective employer ignores twenty years of industry experience to ask you what class of degree you got twenty years ago you begin to see the farcical nature of the situation.
In our hackspaces, we see plenty of people engaged in this educational treadmill. From high schoolers desperately seeking to learn something other than simply how to regurgitate the textbook, through university students seeking an environment closer to an industrial lab or workshop, to perhaps most interestingly those young people who have eschewed university and gone straight from school into their own startups.
How do you get teenagers interested in science, technology, and engineering? [Erich]’s team at the Lucerne University of Applied Sciences makes them operate three robots to get a gumball. The entire demonstration was whipped together in a few days, and has been field-repaired at least once; a green-wire fix was a little heavy on the solder and would short out to a neighboring trace when mechanical force was applied.
The last time we discussed [Eric]’s EduCase project was as part of his Hackaday Prize 2016 entry. There was a lot of skepticism from our readers on the goals of the project, but whatever you think of [Eric]’s motivation, the fact remains that the build is pretty cool. The previous version of the EduCase relied on a Ku-band downlink to receive content from Outernet, and as such needed to stuff a large antenna into the box. That dictated a case in the carry-on luggage size range. The current EduCase is a much slimmed-down affair that relies on an L-band link from the Inmarsat satellites, with a much smaller patch antenna. A low-noise amp and SDR receiver complete the downlink, and a Raspberry Pi provides the UI. [Eric]’s build is just a prototype at this point, but we’re looking forward to seeing everything stuffed into that small Pelican case.
Yes, Outernet is curated content, and so it’s not at all the same experience as the web. But for the right use case, this little package might just do the job. And with a BOM that rings up at $100, the price is right for experimenting.
Getting kids interested in programming is all the rage right now, and the UK is certainly taking pole position with its BBC micro:bit, just recently distributed to every seventh-grader in the land. Germany, proud of its education system and technological prowess, is caught playing catch-up. Until now.
The Calliope Mini (translated here) is essentially a micro:bit clone, but one that has learned from the experience of its spiritual forefather — the connection points are spread around the outside of the board where the crocodile clips won’t accidentally touch each other.
Not content to simply copy, the Calliope also adds additional functionality. A microphone and speaker are integrated onboard, as is a Grove-style I2C connector. They’ve even added a TI DRV8837 H-bridge motor driver, so students could make a rolling robot straight out of the box.
One problem with engineering education today is a lack of experimental teaching. Oh sure you may have a project or two, but it’s not the focus of the program because it’s hard to standardize a test around. Typically sections of the field are taught in a highly focused theoretical course by a professor or graduate student with a specialization in that section. Because classes treat individual subject areas, it’s entirely possible to get a really good understanding of two pieces of the same puzzle, but never realize that they fit together to make a picture. It’s only when a freshly minted engineer gets out into the real world that they start to make the connections between seemingly disparate fields of knowledge.
This is why Carroll Smith’s book “Engineer to Win” is so good. He spent a lifetime as a practicing engineer in a field where a small failure could mean the death of a friend. So when he set out to write a book, he wrote a book that related everything needed to properly conceptualize and solve the mechanical engineering problems in his field.
One warning though; the book is not for the faint of heart. If you want to learn something difficult well, then this is book for you. Carroll skips the comforting analogies and gives the information exactly. It can get a little dense, but he makes the assumption that the reader is there to learn and, most importantly, understand. This takes work.
For example, you can’t really understand why a rolled bolt is stronger than a bolt cut on a screw machine until you understand how metal works on a crystalline level. The same goes for metal fatigue, brittle fractures, ductile failures, and all the maladies that metal can suffer. The difference between an engineer and a technician is this deep understanding. Otherwise the equations learned are just parts in a toolbox and not paint on an artist’s palette.
This is why the first half of the book is dominated by all things metallurgical. The book starts with the simple abstractions of the crystalline structures of metal. Unlike my materials class in university, it maintains a practical bend to the presentation of the information throughout the whole process. For example, it moves on to what all this practically means for metals undergoing stresses and failures before it launches into a (short) digression on how metals are made and their history.
This first half of the book touches on non-ferrous metals and their proper use as well. After that comes some of the best explanations of metal fatigue, fasteners, and metal bonding I’ve ever read. When the failure of a joint causes a mechanism to fail in a toaster that’s one thing, but when it fails in a racecar people get hurt. Carroll is very exacting in what constitutes a forgivable oversight in engineering, and what does not.
Once the book has finished conveying a working understanding of metals and fasteners it seems to fracture into a pot-luck of different racecar-related topics. During my first reading of the book I resisted this strange turn of events. For example, I didn’t really want to read about racecar plumbing in the eighties, or what kind of springs and aerofoils Carroll likes. However, when I reread those sections in a more focused manner, I realized that many of them were teaching the practical application of the knowledge learned in the previous chapters. How does the metal make a good spring? Why is one kind of plumbing better than another?
Importantly, the anecdotes at the end of the book impart an understanding of the importance of professionalism in engineering. What is the true responsibility of an engineer? He teaches not to take the trust others place in your skills for granted. He teaches to trust in the skills of others. The book teaches humility as an engineer. He shows the kind of person one can become after a lifetime of earnest study in their craft.
Thanks to reader, [Dielectric], for recommending the book to me. Also, from the bit of research I’ve done, the older motorworks edition is generally considered to have better quality reproductions of the diagrams than the newer printings of the book.