Member Since: May 22, 2009

Country: United States


Spoken Languages

English and some French

Programming Languages

C, C++, Perl, Python, FORTRAN, BASIC,


  • I did not mean to indicate that chip did not document the issue with the delay. Even the datasheet from 5 years ago had this documented. What I found aggrevating was having to wait the 2ms before getting to read the in service register. Of all the chips I have used in 25 years of electronic design, this is the first time I have seen an interrupt pin requires a delay before reading the ISR. In my opinion it is a terrible design. Yes, you can work around it.Just make sure you do not wait the 2ms in the interrupt service routine. You need to set a flag or a timer in the ISR and check it in the main loop. This "feature" made it tough to use in a very limited resource micro like an MSP430.

    I am glad to hear the Sparkfun's library accounts for this issue.

    Interesting that they recommend gating the events with other sensors. That I think must be new in the datasheet. I did not see that in the original version.

  • I purchased a very similar breakout board from a different vendors years ago. I am trying to protect a fairly significant investment in computer gear by power it all down and disconnecting from power when a storm comes by. I found this chip (not the break out board implementation) to be much less than satisfactory. First if the detector is keep inside, every time some motor kicks on in the house (AC units, furnace blower, dishwasher, disposal, ...) I would get a false alarm. If I reduced the sensitivity (via registers) then I would miss storms. I never did try this outdoors away from the house because of the difficulty in getting power to it.

    The second problem is again with the chip (not the breakout board). They provide an "interrupt" pin to tell you of events. The problem is that when the interrupt pin is asserted, the interrupt service register (tells you why you got the interrupt) can't be read right away. You have to wait an ungodly amount of time before it becomes valid. If memory served me right something like a few milliseconds. Makes having an interrupt pin pretty idiotic. When the interrupt happens, you need to kick off a timer in you interrupt service routine. When that timer expires, then you can read the service register. Why you could not have held off the interrupt till the register was valid is beyond me. It is a huge bone headed error.

    After several months of screwing around with the chip, it went into the junk drawer and I built a much more reliable detector from an old AM radio.

    Again, I am sure the Sparkfun board is just fine (although I have not purchased one). It is the chip itself that has the issues.

  • One nasty issue with these header housings. They are not the correct width. Rather than 0.2 inches wide they are 0.2250 inches. So where the male pin connectors can be placed side by side (they are 0.2" wide) the females will not fit more than 2 or 3 abreast. Since I had already arranged the circuit board for the males to be side by side, I was forced to sand each frigging female so they would fit. Not happy. Not happy at all.

  • This design is not helpful for multi drop RS-232 networks. The transmit enable and receive enable-not are tied together and controlled by the transmit pin. This is fine for simple point to point networks. With this configuration you can't properly determine if you had a collision on the bus should two devices try to talk at the same time. The solution is to always enable the receive buffer and only enable the transmit when the mode wants to transmit. In this way to receive the bytes you transmit. If those bytes are identical, you had no collision. If they are different you did, and your software can take appropriate actions to re transmit the data. You have had the same problem with all your 485 devices. And each time I use one, I have to cut lift a pin and tie it low. Could you at least not have put in a solder jumper as I suggested in a similar comment for your other 485 BOB?

  • How about getting a panel mount female to go with this?

  • I purchased one of the very first IBM AT computers with an EGA screen and a 40 meg hard drive. Cost a fortune even with the 50% employee discount. I spend many evenings exploring how this beast worked. One thing that drove me crazy was a graphics library I had gotten (EGAD). Every time I disassembled a section of the code, it would be different. The code for drawing a line would change from invocation to invocation. It was only much later when I had to write my own graphics library that I realized what was going on. The library had used self modifying code to optimize the generic line draw routine. If you called a method to change any parameters of the line (dashed, color, thickness, ...) that method would rewrite the line draw routine.

  • I suppose this is a matter of taste, but most systems that use RS-485 in the military world use it because it allows for a multidrop system with limited number of wires. In such systems it is important/critical to know if you have had a bus collision. For this reason, the receiver is always left on. When you transmit, you read back what you wrote. If they are the same, great; if not, you had a collision and must rebroadcast. Very similar to Ethernet.

    If in the commercial world RS-485 is only used for single duplex single master to slave setups then their implementation is fine. Otherwise I contend they have their heads in a dark place.

    Not that Sparkfun reads these comments (its been two YEARS since I posted), but if they do, I would suggest the next revision of the board include a solder jumper to allow for a "receiver always on" mode. By default it would connect the /RE and DE as right now. Add or remove the solder jumper and the recieve enable would be enabled and the transmit enable would go back to the micro. Should only add the cost of one resistor and a bit more copper.

    As for considereing other options, I would love to, but I am dictated by my customer. Its been a while, but I think I was able to lift the receiver enable pin and tie it appropriately.

  • Please stop trying to be cute with the video transitions. All the pulling of focus and panning into products is making me nauseous! Straight cuts work very well and look more professional.

  • I think the 7mm dia output shaft is also in error. I think the bronze bushing is 7mm and the shaft is 3mm from the datasheet.

  • 1) Would anyone care to guess how high the SparkFun building is? Would like to know to estimate the GPS error due to building masking.

    2) Could an email address be established for submitting AVC questions? Answers that would seem of general interest could them be posted on a read-only thread on the Forum. This would be a better and more formal solution than posting to this comment list.