signal7

Member Since: October 16, 2008

Country: United States

  • I asked the question because I can’t depend on the manufacturer to keep their documentation online. When they release an update to their module, their documentation will disappear. On the other hand, if SFE hosts the documentation, then it’s available for everyone in the community.

    Yes I could have gone to the manufacturer website, but this is, in my opinion, better for everyone.

  • No command reference? How do I talk to this module?

    Also, the datasheet does not indicate if this module can communicate with another BLE slave device or if it’s only intended to act as a sensor node communicating back to a host computer. I’m thinking the missing command reference might clear that up.

  • To me, a fitbit is not a ‘wearable’ technology and neither is the Apple watch. They are accessories of a sort that are not integrated into one’s clothing. These kinds of technology I’ll gladly buy and use because they aren’t integrated into a particular article of clothing.

    Historically, when Sparkfun refers to wearables, it usually means that the electronics are part of the clothing itself. These things I will not buy and I have no care in the world for even experimenting with them. The core problem to me is that I have to have one particular item to receive the benefit of the technology or I have to buy that same technology multiple times for it to be feasible. I’m also not convinced that such things are terribly durable given that most things must at least be washed at some point in their usage lifecycle.

  • I have to admit, AMD does graceful failure unexpectedly well. I had the misfortune of using a computer where the CPU fan was disconnected from the header on the motherboard. Either the wire wandered it’s way too close to the fan and it got yanked -or- a certain person forgot to plug it in.

    I used the computer for months that way - even playing games on it - and it worked fine. The only thing that indicated something was wrong is the system would unexpectedly slow down when the processor got near it’s thermal threshold. Once I corrected the problem, it was fine. Apparently someone at AMD knows all too well how good those ‘ball bearing’ cpu fans work.

  • I learned programming at the ripe age of about 12. Back then, the standard computer in my school was an Apple ][e and all anyone did with them is write in basic. It turns out that I probably didn’t appreciate that skill as much as I should have until many years later.

    My job in college was to repair VCR’s and televisions for a media department in the library. I worked there anytime I wasn’t in class during the day and most of the equipment back then was designed to be repaired. We even had service manuals for everything.

    You might be thinking that job was easy, right? Well, no. Even though you have the manual, you still run into situations where you have to work out how a circuit works and then figure out what it is that’s making it malfunction. It didn’t really matter that you had the full schematic and the values of a few test points. The design of the circuit was not documented anywhere so you had to figure out a lot on your own.

    I initially found this frustrating. I was several years into my degree in electrical design and still had some projects that I couldn’t really figure out. I asked one of my co-workers to take a look at a problem I was having (he was a photography major) and he very methodically worked out the absolute logic that had to be followed to determine how it worked and where it had malfunctioned. In short, he used the one skill I hadn’t thought to use and solved the problem in no time.

    I do a lot of sysadmin support and I’m still finding that education in logic to be very useful. People come to me with issues and I do my best to figure out logically why something isn’t working. The people I work for can be fairly irrational. “The mouse only works when I press on this corner of the computer’s case” is one example. “It just doesn’t want to work today” is another. In reality, the day of the week has nothing to do with why something isn’t working. Usually the problem is something entirely unrelated like not allowing their favorite pet to chew on the cords in back of the computer.

    I don’t think an education in programming will solve that last bit, but I don’t think it would hurt either.

  • I know everyone dislikes doing mortise & tenon joints, but seriously, you’ll use a lot less material, the desk will be lighter, and it won’t have all that bulky triangulation. To do them, all you need is a mallet, a mortise chisel, handsaw, and a sharpening stone. It doesn’t have to be overly complicated or expensive.

    Pocket screws might speed things up but I’ve never liked having metal potentially hidden inside of a project. At some point you may decide to repurpose the lumber after you build Desk 3.0 and there’s nothing more frustrating than chipping a carbide blade on hidden fasteners.

    Also, you might be able to get away with using bed hardware instead, but I’ve never tried that. On the other hand, most beds are fairly stable and they don’t have mortise & tenon joints.

  • Is there a published MTBF for this product? I know it has metal gears, but the material the gears is made from won’t matter much if there’s a bearing failure. My application would have this running for weeks at a time 24x7 at the fully rated voltage. It’s not a high torque application, if that makes any difference. It’s running a magnetically coupled stir bar which slowly mixes a fluid in a container above it.

    Anyway, I just finished building it and was curious.

  • Links to some of these products would have been a nice addition. I had to search online to find the global supply website and then search individually for items shown in the write up. I not only have an electronics workspace, but a nearly complete wood shop in my basement. Getting those organized is something I have to continually work on and the items mentioned above may improve that. Great write up otherwise.

  • I’ll tell you what I tell everyone about fixing cars, washing machines, furnaces, etc.

    Most products, no matter what they are, have relatively few failures that are completely random. Much of the time a particular product will have the same failures over its lifetime and people will post their problems online.

    When the windshield wipers didn’t work, the first thing I would do is go to google, enter year, make, model, and failed component. 80-90% of the time, someone else has already encountered the problem and fixed it. When there was a high pitched squeal coming from under the hood of my Saturn, I went online and found out that the water pump nearly always dies after 120,000 miles. Sure enough when I replaced it, I not only found that it was in the process of failing, but the bearings were so loose they couldn’t hold the pully straight.

    Go forth and google. It will save you a lot of messing around reinventing a solution. :-)

  • The reason you want to verify your code upload is because flash memory eventually wears out. If you go through a lot of upload cycles during development you will eventually find the limit where your flash memory is suddenly read-only. Even worse, you’re overwriting the same locations with every upload - there is nothing to make it so you wear every byte of flash evenly like there is in an SSD.

    I know I can go through a thousand uploads or more during the course of a year and I only own a couple of full size arduinos. Generally my work moves to a pro mini version once development is complete.

No public wish lists :(