Peter Pan

Member Since: September 24, 2012

Country: United States

  • With all due respect, I appreciate your answer but it is not very helpful. Its always easy to say “start over this way”. Engineering or devising a way to save an existing project is much more difficult. Its not the “Hubble” telescope I’m talking about here, but in i a sense its MY “Hubble”. I can’t afford to start from scratch.

    I didn’t say I was planning a project and now have to change my plans.. These are nearly finished products which at this point I have a couple of years and multiple thousands of dollars invested. There are PCBs, enclosures, labels, and not to mention a significant amount of code that has gone through several modification cycles. Starting over with a different core module is simply not an affordable option.

    If anything, I’m guilty of assuming too much about the WIXEL module I started with. As far as I can see, their designers (Pololu) have ) followed TI’s design guidelines to the letter, for the embedded CC2511F32 MCU, including the design of the PCB trace antenna implementation. So it is unlikely the project wouldn’t pass muster with the FCC. And I always assumed that if the product was successful, I’d eventually have to invest (or get investor funding) to do the whole FCC certification. But I wasn’t prepared for the FCC law forbidding me to make a dime even selling 5 prototypes.

    So what I was trying to gain from my post here, and similar posts on other forums, was to glean actual experience of others in my position, who have either discovered some reasonable legal work-arounds, and/or have discovered that they actually were able to sell a reasonable number of products. Perhaps someone might share ways to do some of your own testing, to at lease ensure you don’t get complaints from interference. And as it stands now, I have heard from some people (although privately for obvious reasons) that they have sold low power devices that don’t have interference problems, for a VERY long time. I continue to seek more helpful ideas from anyone willing to share.

  • For what its worth, this is a sad story. I now have prototypes of a very useful and highly programmable remote 2.4 Ghz control system for musicians and DJs, which I very much will want to test market soon. I originally designed the system for myself, since no one made what I was looking for, and this is what is inspiring me want to make it a product. But as a remote control, it is an intentional radiator. So it is more than a major shame that I, as an American innovator, have no practical financial means to move forward without investor income. That is an option I will pursue, for sure. But in the mean time it would be more than nice if if someone could advise me on a reasonable approach to a test market. The fact that almost any product will need to undergo some changes after a test market, which could potentially mean the previous 10,000 was wasted, pretty much makes me want to give up. I knew I’d need FCC approval at some point, but $10000 is obviously pretty depressing for all but deep pocked inventor.

    Hopefully I can get some reasonable advise on how to “work” the system. Perhaps inviting initial customers to become a kind of partner, offering a product discount ( or a cash back payment) in exchange for their service, providing product feedback. Or perhaps I can use the old “for educational purposes only” gimmick. I don’t know. If anyone has anything useful to offer here, please contact me privately via the contact link on my “under construction” site, elfintechnologies.com, as the advise will be much appreciated.

    Now please understand my dilemma, and please do not lecture me on the reason for FCC rules. I understand them fully. But as an innovator and out of work engineer, that has invested a lot of personal finances, time, and dedication to making a good product, I am hugely frustrated to find out that testing my product will cost so much. I took great pains to design something that based on the manufacturer’s guidelines would harmlessly generate the equivalent RF power of a children’s toy, on the largely unregulated 2.4 Ghz band. What a wonderful feeling to know the cost of certifying it will be more then I’ve spent on the prototypes, and will potentially put me out of business before i start.

    There really should be some kind of developer’s temporary license available on certain unregulated bands (like this one), that grant the developer something a little beyond 5 units, or forbid you to make a dime on any one of them. Maybe there is and I’m just reading all this wrong.

  • Because of its small footprint and tall shaft, this button spared my project from having to devise separate actuator mechanisms to extend each button up through a panel. (my project uses 8 of these, very closely spaced). But I have observed that the mechanism is somewhat delicate. These buttons can easily be compromised mechanically or rendered unusable with too much lateral pressure. Trust me, this can easily happen by accident during testing, handling, or while soldering additional components. Needless to say, replacing a switch already soldered into a PCB is a pain.

    Of course, once your final assembly is mounted so that the shafts pass through holes in your panel, they are protected from lateral motion. But in the mean time I strongly recommend making a kind of temporary front panel to protect a PCB assembly using these buttons. A spare piece of PC board with 1/8" drill holes (for the button shafts), mounted with 3/8" spacers works perfectly, providing a neat 3/32" of button shaft access for operation.

  • I’m actually surprised you found so much jitter , and I wonder if you just got a bad unit. I’ve been using this encoder for several months, as I was testing it for a Wixel based application, and I was finding it to be very stable… certainly very rare a transition would happen without even touching it. Couple of things though. First, I realized a big difference is that I am “polling” (sampling) the encoder at a rapid but constant rate rather than interrupting on change as you are. My premise is that regular polling offers some of the protection from excessive processing that a denounce routine would offer. You could do the same thing with an interrupt based on a timer rather than on a state change. I basically calculated the max reasonable number of transitions I could expect within a given time, with someone making a fairly rapid adjustment. As long as I was “polling” at least 2X or 4X faster, I’d be safe from losing ANY counts. (In actual use, usually losing SOME counts from a human operated control is acceptable too). Anyway, it seems to have worked out well. There’s no way to make an interrupt on state change intelligent, as the interrupt has to do some time based processing just to see if it was valid. And really, doing any kind of delays or waits within an interrupt is asking for trouble, because a badly jittering contact could start eating all your CPU time. The other thing, as I’m sure you’ve heard before, is that with the gray code output from these encoders, the worst that could happen with a properly written routine is that the final output (the accumulated count) might be +/- 1 off. But really, +/- 1 counts is considered to be the maximum practical accuracy in any digitally acquired count.

  • Hey, don’t laugh, but in the past I’ve almost always smeared a light layer of soldering paste over SMT pads on a PC board before soldering a part down. Seems to work pretty well, but is there a better flux to use for this purpose?

  • Will this work for what TI is calling their “narrow SOIC” package? I need to experiment with some Low Voltage OP amps in this case LME49721, and i can’t imagine doing so without the ease of whit boarding. The TI data sheet for this chip at http://www.ti.com/lit/ds/snas371b/snas371b.pdf but I don’t see any reference to whether or not is “JEDEC SOIC”.

  • Well no matter what, you won’t be able to drive a relay coil directly from an MCU. BUT, it definitely is convenient to not require a second power supply! So here’s part at mouser I’m looking at. The 3V version Need 60mA to trigger the coil, but with a diode protected transistor buffer, it should work OK with a 2 or 3 cell supply.

    http://www.mouser.com/ProductDetail/Omron-Electronics/G6L-1P-DC3/?qs=sGAEpiMZZMs3UE%252bXNiFaVKvMl4Uo7aSY79LeLFQ9WdI%3d

  • I bought these because I wanted to experiment with a pair of Wixels, and wanted to avoid having to solder in the standard headers Pololu provides. The through holes seemed pretty loose, so an ordinary header would not make good contact on its own without solder, so this product looked ideal. Unfortunately now that I have them here, I see that I simply can’t push even a few of these pins through the Wixel through holes, without applying an uncomfortable amount of pressure. The wixels are almost $20, so I’m not going to press further and risk ruining them. I even tried pushing these headers into an experimenter board first, hoping their firmly held position might make it easier to rock the wixel board back and fourth and eventually get the expansion pins to fully seat. Doing so barely allowed me to get the wixel board to hold in place. But they are still not even going fully through the holes from one side of the board to the other. I guess I can try modifying the product, but if I’m going to do that I might as start with ordinary headers, coating one side with a thin layer of solder to make a better force fit. In any case, I’m sure they work fine with some product the designer had in mind, but this is my experience.

  • I want to ultimately convert the codes to tell a audio volume control IC to step the attenuation up or down. Most such chips resolve to about 1db per step, so to have rotary encoder behave something akin to what one would expect in a volume control, I’m going to need about 128 PPR. I’ve been looking all week and have come to conclusion only expensive optical units with offer any PPRs > about 32. So before I start looking for an inexpensive gear arrangement, does anyone know of a a better product for me to look at?

No public wish lists :(