John Morris

Member Since: February 18, 2008

Country: United States

  • Actually, that is not a hardware flaw. Out of the gate every Atmel micro has the ClockDiv8 fuse programmed. This is explicitly so every user can make their desired clock selection without exceeding the rating, since dividing by 8 assures you have a safe speed. Leaving that fuse programmed makes it a simple software issue, if you are running at 3.3V and want to play it strictly "by the book" all you need do is never select /1 on the clock divisor. /2 will give you 8MHz which is probably fast enough and within bounds at any of the voltages you are using.

    If you are using a bootloader like Optiboot you will need to take this into account when you build and flash it. Set it to run at the default /8 speed of 2MHz and you are good to go.

  • Without knowing the range of use cases, can't say for sure if it is a flaw. The thing I noticed was that you used fairly large power MOSFETs but placed them such that you can't mount a heat sink. If you flipped them 180 you could. Was also thinking they were also sticking up a bit, could be prone to getting whacked loose, that there was enough unused board space to permit laying them flat and getting a fair amount of heat sinking as bonus. However looking at a different angle shows those caps are almost as high so perhaps not as big a problem?

  • Eh? Sure you have the right datasheet listed? The one you list says in four pin mode it accepts eight bit bytes and the ninth bit is delivered on the fourth pin. Plus you could just go with parallel. Yea it burns a lot of pins but if you are expecting to read the display memory in a read / modify / write operation the speed might be worth it.

  • Seems like this is just all wrong. The datasheet for the relay used says it wants 9V minimum to engage and you are trying to run it on 5V, then you used a regulator too small to deliver enough current to drive all four at once. Worse you have the coils on the regulated supply with the data so you pretty much voided the benefit of the optoisolators since you have a direct path for spikes to get from the relays to the digital side.

    Seems like all existing problems would vanish if you relabeled the DC jack 9-12V, reroute the relay side V+ to a point between the reverse polarity protection diode and the regulator and recalculated the dropping resistors for the indicator LEDs.

  • Not really, one rotation of the device is a frame, the pixels and scan lines are just radial in your case instead of top to bottom then retrace. Yes the difference between inner and outer sections can be taken into account, if you have to push the rate to get an acceptable display or are just a masochist. That way leads to CAV, CLV and ZCAV from laserdisc and high speed CD drives all over again except you are always moving the entire thing at a constant rate and varying the pixel rate based on distance from center. It gets messy fast.

  • Best not to think in terms of "Frame Rate" for this sort of thing. Think line rate and 10,000 per second isn't even NTSC quality. So don't ask if you are pushing it too hard, ask if you can push harder. In general MOAR is always better.

  • There is one really BIG issue to consider in the build vs buy. The Cloud. Almost every off the shelf product is tied to the vendor's Cloud these days. It is great when a product offers that tie-in as default because it lets you get up and running faster. But always go in assuming that after a few mergers and market repositionings the Cloud will vanish. Remember Pebble.

    If the off the shelf solution becomes a pet rock without the vendor, cross it off the list.

  • Think everyone is missing the big question here. If you are just dumping Open Source over the wall, like Google with Android for example, then you can go closed. Once you take contributions from the outside, once you actually take the benefit of Open Source, whether it is under a BSD like license that technically allows it or not, you ARE going to make enemies. If you are using a copyleft style license of course you can't go closed unless you get every contributer to relicense or dump their contributions.

    One other consideration. Closing your source does NOT take back the stuff already given away so what usually happens is a fork from the last open version begins in the community while your closed version must compete against it. Ask those who have tried that model how it worked out. Best to do it right as you merge in some major, labor intensive and hard to replicate new functionality.

    And second the recommendation to read CatB, all this stuff was carefully argued way back then and still applies today. ESR sold much of the corporate world on Open Source with that book.

  • Wouldn't $65 spent on a low end Android phone yield a better camera, faster processor and richer choice of programming environments? You would get a USB2 connection fast enough to stream live video and a fast enough system to make it possible to do that AND do various recognition processes locally. Only downside is losing the serial / spi and i2c outputs and the IR capability and since this product doesn't feature a controllable IR cut filter it is a dubious feature at best.

    At some point repurposing mass consumer products becomes more practical than making a more hacking friendly board out of the obsolete parts that small manufacturers can get parts and datasheets for.

  • Suggest you list a mating connector as a recommended product.

No public wish lists :(