While the following may not be useful to most people, in the event that you need to convert FIT file timestamps produced by a Garmin product, this is a time-saver. For whatever reason, Garmin created their own epoch, which began at midnight on Sunday, Dec 31st, 1989 (the year of Garmin’s founding). And as far as I know, all Garmin products log data using this date as a reference. The conversion is simple, just add 631065600 seconds to a Garmin numeric timestamp, then you have the number of seconds since the 1970 Unix epoch, which is far more common (this is the reference used, for example, with the System.currentTimeMillis() call in Java). Hence, the following calculator:
Hard to believe it’s been more than five years since my last post… well, time flies. A great many things have happened in that time, but I’ve logged back in to announce just one: the launch of the Garmin Impact bat swing sensor. The Impact is a training device for baseball and softball players that provides measurements and feedback on their swings and makes recommendations for improvement. It does this via an on-device display, as well as through an accompanying mobile app.
The Impact has been my primary focus for almost two years now, and I have taken part in everything from its PCB design and algorithm testing, all the way through to app development and sales training. It’s been a great excuse to visit the batting cages during working hours. I’ve also learned more than I ever wanted about iOS and Android development. Don’t even get me started on Swift…
But enough about me, let’s talk about the sensor. The Garmin Impact is powered by an accelerometer and a rate gyro, which together sense the orientation and position of the player’s bat throughout their swing. This allows us to compute five metrics: bat speed, hand speed, time to impact, elevation angle, and attack angle. We can also display the full swing path in 3D via the mobile app, with color-coding to indicate areas of high (red) and low (green) bat speed, with impact indicated by a purple line.
Now while other bat sensors exist today, the Impact is the only one to provide an on-device display, which allows for operation without a phone/tablet nearby. Just take a swing, then turn over your bat to view your five metrics, as well as a coaching tip (optionally shown every three swings). This instant feedback allows you to quickly make adjustments to improve your swing or to train for different scenarios.
The Impact mobile app allows you to explore your swings in full 3D detail, and provides images and extended descriptions to the shortened coaching tips displayed on the device. It also allows users to create and customize multiple bats and batters (as the device itself has only two buttons, entering batter names would be a headache). The app also enables your phone’s camera to capture swings, with triggering provided by the sensor itself. All you have to do is select “RECORD” and then point your phone at the batter – the sensor and app do the rest via their BLE link.
The sensor is ready to ship today via Garmin’s website (Amazon coming soon). The mobile app may be downloaded for free via both Google Play and iTunes. Any questions, please let me know! Oh, and the Impact sensor marks the first product on Garmin’s Baseball and Softball page, so stay tuned for more new and exciting tech on the way!
Lately I’ve been doing a lot of work on a fairly complex LabVIEW application. It utilizes a number of controls and indicators which have vertical scrollbars (e.g. text boxes and arrays). This gives users access to a great deal of data without over-crowding the front panel. Unfortunately, LabVIEW does not natively support scrolling via the mouse wheel. Well, I happen to like the scroll wheel, and so do many of my users. So this week I finally went online and found a fairly straight-forward means of implementing this functionality. You don’t need any crazy DLL calls or APIs; LabVIEW’s “Input Device Control” palette offers this functionality (located under the “Connectivity” section). I found this particular example very helpful.
I did run into one rather odd problem though. On my computer, the “Scrolling” value I get using the “Acquire Input Data” block is differential, not absolute. In other words, when I move the wheel one step, the value of “Scrolling” is 120. If I scroll no further and poll again, “Scrolling” is back to 0. However, on the second computer I used to test this function, I received an absolute value. In other words, if I move the wheel one step, the value of “Scrolling” is 120, but then it remains at 120 until I move the wheel again. For instance, if I move the wheel by one additional step, “Scrolling” is now 240; the overall value is cumulative (an absolute position).
To combat this problem, I came up with a fairly simple (but not exactly elegant) algorithm that attempts to detect the mouse type based on the first few values of “Scrolling.” If the absolute value of this parameter ever exceeds 3000, we assume the mouse is of the “absolute” variety. Otherwise, if we’ve seen this value change more than 10 times without exceeding 3000, we assume it is of the “incremental” variety. Until these 10 changes are seen, all scroll input is ignored. This can be a bit frustrating, since the first time a user attempts to scroll something, they’ll have to move the wheel for a second or two before the GUI responds. However, in the case of my application, I then store the mouse type in the registry, so that the next time the program is launched, the scroll wheel is immediately functional. No big deal. If anyone out there has better ideas though, feel free to let me know!
Anyway, you can click on the block diagram below to get a larger view of a quick demo application I built. This demo shows how you might use the scroll wheel to control text boxes, arrays, sliders, and even graph axis scaling. You can also download the example ZIP file below. Feel free to leave comments or questions below. Thanks!
Download: scrollwheel_example.zip (85KB)
Well it’s hard for me to believe, but I’ve now been using National Instruments LabVIEW for six years. I started off with LabVIEW v7.1 and have used every version since (it’s now called LabVIEW 2010). So I’m definitely a fan. And yet, I’m still discovering new and more useful features on a fairly routine basis.
Just the other day I was looking for a convenient means to save a ton of front panel control values to a file (to allow the user to save their current program setup for later use). In the past, when saving program settings, I’ve used the Configuration File VIs, which make saving simple parameters very easy and neat (think header-based *.ini files). However, in this case I needed to save an obscenely large quantity of very variable data (numerics, strings, booleans, arrays, clusters, clusters of arrays, arrays of clusters, etc…). After a bit of Googling I found my answer, the magical Datalog VIs (located on the Programming → File I/O → Adv File Funcs → Datalog palette):
The Datalog VIs allow you to save clusters of any sort to a compact, record-based file. Of course, you aren’t required to make use of the record functionality, you can just store everything in a single record and then recall that record later. For instance, I packed the following mass of controls into a single datalog file with just a few simple blocks:
Reading from a datalog file is just as simple, you need only swap in a read block in place of the write block. Here’s a bit more on the Datalog blocks, taken from NI’s website:
A datalog file stores data as a sequence of identically structured records, similar to a spreadsheet, where each row represents a record. Each record in a datalog file must have the same data types associated with it. LabVIEW writes each record to the file as a cluster containing the data to store. However, the components of a datalog record can be any data type, which you determine when you create the file.
For example, you can create a datalog whose record data type is a cluster of a string and a number. Then, each record of the datalog is a cluster of a string and a number. However, the first record could be (“abc”,1), while the second record could be (“xyz”,7).
Using datalog files requires little manipulation, which makes writing and reading much faster. It also simplifies data retrieval because you can read the original blocks of data back as a record without having to read all records that precede it in the file. Random access is fast and easy with datalog files because all you need to access the record is the record number. LabVIEW sequentially assigns the record number to each record when it creates the datalog file.
So there you have it! If you’re looking for an easy way to store diverse data, the Datalog VIs may be your answer. Oh, and if you’ve got no clue what graphical programming with LabVIEW is all about, check out NI’s free 30-Day LabVIEW Trial. The trial is full-featured; the only catch is a small watermark placed in the lower right-hand corner of your VIs. But give it a shot! It takes a little getting used to if you’re a die-hard C programmer, but once you understand the basics, you’ll be churning out sophisticated programs in a fraction of the time required to type code.
Plasma. You’ve probably heard of it before (and hopefully somewhere outside of Best Buy). It is the fourth state of matter (the first three being solid, liquid, and gas), in which molecules have been split apart into their most basic atomic form and ionized. Accomplishing this splitting, or disassociation, requires huge amounts of energy. So it’s not surprising that plasma plays a key role in a number of high-power applications including plasma cutters and fusion reactors. Again, you’ve probably heard of those. But I’ll bet you’ve never heard of dental plasma torches or plasma arc waste disposal.
So what’s the deal here? Using plasma for waste disposal? Sounds like overkill. I mean, vaporizing trash with a torch that reaches temperatures of 25,000°F? That’s more than twice the temperature at the surface of the sun. Well, there actually are advantages to this. For one thing, plasma torches can break down almost any material into its constituent atoms. Plastics, metals, toxic compounds, medical waste, apple juice – basically anything except heavy radioactive materials (such as spent nuclear fuel rods) can be converted into gasses and slag (molten solid waste, shown below):
As an added bonus, with plasma arc waste disposal, the byproduct gasses can actually be used as fuel. In fact, these plasma converters, as they’re called, can generate more energy than they require for operation. In other words, they convert waste into energy, similar to an old-fashioned incinerator. But unlike incinerators, which burn waste in the presence of oxygen, plasma arc furnaces break apart waste using a process called pyrolysis, which can be done in an airtight container. The result? Fewer hazardous byproducts.
Anyway, I’ll stop here and refer you to HowStuffWorks for further information. They’ve produced an excellent article on plasma converters which goes into more detail on how these systems work and where they’re currently being designed and used.
In other news, yes, this is my first post in three weeks. My apologies for being so lazy, but I’ve been a little busy with moving from Troy, NY to Waterloo, IA for my new job with John Deere. I’ve just wrapped up my second week of work and it’s been pretty exciting so far. During my first week of orientation I toured a different Deere facility each day. I saw some pretty amazing things there, including electrostatic painting robots, inductive heat treatment, and some pretty hefty robotic welding stations. Perhaps in the future I’ll be able to write about some of these things (although the details of a lot of these systems are confidential). Anyway, to my subscribers, thanks for sticking around!